Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] GPG verification

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Sukneet Basuta <sukneet AT gmail.com>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] GPG verification
  • Date: Tue, 13 Dec 2011 23:54:03 -0500

On Tue, Dec 13, 2011 at 4:16 AM, flux <flux AT sourcemage.org> wrote:
> Sukneet Basuta (sukneet AT gmail.com) wrote [11.12.04 15:27]:
>> I also move to a vote that Source_Integrity_Checking_Standards [1] be
>> modified to state that upstream signed sources (i.e. verification levels
>> UPSTREAM_KEY through ID_CHECK_UPSTREAM_KEY) must be supplemented with a
>> hash of the signature and that it be implemented on the next major release
>> of sorcery (0.16).
>>
>> [1]
>> http://www.sourcemage.org/projects/grimoire/wiki/Source_Integrity_Checking_Standards
>
> There is a problem with this. You can't make the grimoire rely on
> features that are not yet in stable sorcery, as that would invalidate
> the grimoire for everyone using stable sorcery. Thus, you would have to
> require this to go into sorcery *first*, and only after it percolated to
> stable sorcery (it goes into devel first, then test, and finally stable)
> could you argue to have it required for grimoire.

I was thinking that spell maintainers could for now just set the hash
of the signature to a set variable (for example SIG_HASH). It will be
ignored by current versions of Sorcery, but will prepare the grimoire
for the change, which will obviously take a while to do.
I was also thinking that the signature hash should be optional in
sorcery, at least upon introduction. That is, if SIG_HASH is missing,
spells would still cast fine. This is advantageous to us since there
are quite a few spells in the grimoire (with a decent amount
unmaintained) so it'll take quite a while to update them all.

> I think it would be better to first have a discussion/vote on whether
> this is actually the best way to implement what we want to have.
> Probably it's not worth it to have a discussion, since this thread has
> already been going for a while and only a few of us are chiming in, so
> you'd probably only get the same voices regarding implementation. Still,
> calling a vote on whether we want it implemented first (vs. any other
> options we can think of) would be better before calling a vote on
> whether we enforce it, IMHO.

That's fine. I was merely trying to get things going. No one seconded
my motions for a vote anyway and it been more than a week—unless David
was seconding the motion by saying he was going to work on it.
Maybe Bor's idea to first draft a new set of standards and then vote
is the proper way to go about this.




Archive powered by MHonArc 2.6.24.

Top of Page