Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
  • To: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] STRONGER POLICY for gpg signatures to replace MD5[*] and ALSO new SOURCE_HASH support
  • Date: Tue, 30 Aug 2005 17:25:06 -0400

Quoting Seth Alan Woolley <seth AT positivism.org>:

As I said, if you can show it's a common interpretation of signatures
that they mean something trascendental to what FIPS-186 denotes, I'm
willing to add support for spell signing directly to sorcery (which
creates a level of indirection that you should be content with). That
brings up the problem of increasing complexity of code and might lead to
a failure of users to trust the system due to its increased complexity.
So the "amount" of misunderstanding would have to be more than
proportional to the increased compexity that we would be adding. I'd
say it adds 10% complexity to the system if we add direct spell or
DETAILS signing. If you can show that this mistake is common enough to
warrant that increased complexity, I'll agree with you (on this matter
only).

Is the fact that I am not the originator of the tarball enough?

P.S. It has come to my attention that a patch with what you would like
to see would go a long way toward improving your argument's viability.

You mean a patch to sign spells? I was thinking more like an SCM that has this
feature built in.
In regards to keeping hashes, how can I make a patch to not exclude code from
sorcery? Signing commits has little to do with this.

P.P.S. Regarding charred bridges, I think next time you might tread
lighter responding to certain people, although it's really a mutual
suggestion -- I think others have not been as lightly treading as they
could have been as well, myself included.

This entire conversation, Seth, is a waste of everyone's time. Think about it:
we're discussing whether a feature that is useful and widely used in the
project, suddenly has to be removed. There's nothing wrong with this feature.
Somebody decided they don't want it, and I disagreed. It's like removing ATA
support from the kernel because SCSI is better and faster. It's chilarious at
best.

Sergey.





Archive powered by MHonArc 2.6.24.

Top of Page