Public SourceMage Discussion List

[Seth Alan Woolley <seth AT positivism.org>]

On Mon, Aug 29, 2005 at 07:22:43PM -0400, Sergey A. Lipnevich wrote:
> Hi All,
> 
> I can think of the following compromise that would hopefully satisfy all 
> sides.
> 
> 1. Sorcery keeps support for hashes and signatures, both optional, but with
> possibility to be restricted by users of individual systems. Here's one for 
> the
> choice.

We're working on adding a number of choice features in a new sorcery 
menu for the existing system, this shouldn't be much more work.

If hashes are not policied out, I plan on adding support for gpg 
--print-md and openssl dgst support in addition to hashsum support.  
I've already got a backup plan.

> 
> 2. When this option becomes available, we move to digitally sign every
> repository commit. In effect, this will also sign a hash that is stored in
> DETAILS. Should a tarball or both tarball and hash value become compromised,
> our repository will help detect that. For added protection, we can also 
> include
> the size of tarball into DETAILS, effectively signing it as well.

size of tarball doing what exactly?

> 
> This way, we will do exactly what is claimed on that Web page: sign package
> receipt without signing the contents.

a signature is merely an asymmetric encryption of a hash.

What you propose is to make an asymmetric encryption of a hash which includes 
a hash.

Is this level of indirection that meaningful to you?

> 
> How does appeal to everyone?

Signatures the vast majority of the time ensure transportation security, 
not execution security.

They never have meant execution security in the free software world.  A 
friend of mine was working on including binary signatures into linux 
when he worked for Trustix, but the project never carried in the 
corporate world, and Microsoft has included binary signature support in 
ActiveX and its own .Net framework (parted out as updates to existing 
systems and soon to possibly be mandatory in later versions of the OS).

That kind of signature assertion is vastly different than the common use 
of PGP in the free software world.  Even then, how would they know it's 
secure?  The fact is, they didn't.

We're NOT doing that kind of validation.  Redhat signs their binaries 
and srpms -- are they attesting to the security?  Nope, just 
transportation security.  In fact, Microsoft has been the greatest 
misinformer of the utility of digital signatures.  Digital signatures 
make not a secure system.

FIPS 186, the DSA standard: http://www.itl.nist.gov/fipspubs/fip186.htm

digital signatures = integrity, non-repudiatio

"This standard specifies a Digital Signature Algorithm (DSA) which can 
be used to generate a digital signature. Digital signatures are used to 
detect unauthorized modifications to data"...

integrity (does the whole thing get there uncorrupted? what we're mainly 
concerned about)

..."and to authenticate the 
identity of the signatory."...

authentication (is it really from us? preventing MIM attacks)

..." In addition, the recipient of signed data can 
use a digital signature in proving to a third party that the signature 
was in fact generated by the signatory. This is known as nonrepudiation 
since the signatory cannot, at a later time, repudiate the signature."

non-repudiation (similar to authentication)

regular hashes can only do integrity.  They cannot authenticate in the 
form we use them (but c.f. challenge authentication, requiring two-way 
communication and an already shared secret unique to each user).

Thus they are ideally situated to our task.

That you believe that there's some sort of transcendental property to 
digital signatures confounds me.

If you're concerned about signing things -- generating a special key for 
signing and including the signature inside the spell, distributed with 
it, signed by our private key, protects against people distributing it 
willy-nilly.

Would you prefer we use openssl routines and PKCS to do the same exact 
signing?

As far as your compromise, I have an implementation suggestion:

I'm willing to add code to sorcery to check for a DETAILS.asc file (or a 
$SPELL.asc file with signatures of all files but $SPELL.asc) that uses 
the key pointed to by SPELL_GPG=blah.gpg inside the DETAILS file.

If you're willing to sign your spells like that, that's an adequate 
compromise for me, but it would be an error if you DID NOT include 
SPELL_GPG=sergey.gpg (and an .asc file) and DID use a SOURCE_HASH in a 
spell at the same time under the new policy.

But I don't know how other people will like it :)

Seth

> 
> Sergey.
> _______________________________________________
> SM-Discuss mailing list
> SM-Discuss AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/sm-discuss
> 

-- 
Seth Alan Woolley [seth at positivism.org], SPAM/UCE is unauthorized
Quality Assurance Team Leader & Security Team: Source Mage GNU/linux
Linux so advanced, it may as well be magic http://www.sourcemage.org
Secretary Pacific Green Party of Oregon http://www.pacificgreens.org
Key id FDCEE733 = 5302 B414 64C4 6112 3454  E082 99F0 69DC FDCE E733

Attachment: pgpOIqDsXISaE.pgp
Description: PGP signature