Public SourceMage Discussion List

[Eric Sandall <eric AT sandall.us>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 30 Aug 2005, Sergey A. Lipnevich wrote:
> OK, so we'll talk about wording now?

If you want, but that wasn't my intent...

> Quoting Eric Sandall <eric AT sandall.us>:
>
> > Maybe if I show that the 'common' case of GPG verification for
> > distributions is what the current SMGL policy is (and that's being
> > argued about):
> >
> > Fedora: http://fedora.redhat.com/docs/yum/sn-managing-packages.html
> > "Check the public key, and then press y to import the key and
> > authorize the key for use. If you press N or Enter , yum stops without
> > installing any packages.
> >
> > To ensure that downloaded packages are genuine, yum verifies the
> > digital signature of each package against the public key of the
> > provider. Once all of the packages required for the transaction are
> > successfully downloaded and verified, yum applies them to your system."
>
> We're not providing these packages. Users download them from Web sites.
> We exist
> as a distribution that doesn't rely on the middleman (distributor) to
> ascertain
> that everything is clean. If I wanted a secure distro, I'd have to stick to it
> and get all my packages only from it. We're not in this business.

Who said anything about providing packages? All we're doing is
verifying that the tarball the user is getting is the same tarball the
user got. That's all the vendor's GPG sig (e.g. Fedora) is doing as
well. It's not saying anything other than, "Here's a tarball. Here's
our public key. Here's the signature we signed for the tarball. Make
sure they match and your tarball hasn't been tampered with." All we're
adding is, "...tampered with since the guru updated the spell."
What part of this do you not understand?

> > GnuPG FAQ: http://www.gnupg.org/(en)/documentation/faqs.html#q7.1
> > "GnuPG is also useful for signing things. Files that are encrypted
> > with the secret key can be decrypted with the public key. To sign
> > something, a hash is taken of the data, and then the hash is in some
> > form encoded with the secret key. If someone has your public key, they
> > can verify that it is from you and that it hasn't changed by checking
> > the encoded form of the hash with the public key."
>
> It's not from me. As I told Seth, I am not the originator of the
> tarball, so the
> file is *definitely* not from me.

We never said you were. You can read the above to say whatever you
want, but the intent was to show that GPG can be used to verify the
integrity of the tarball. Hence we're using GPG to verify the tarball
the user downloaded is the same as the tarball the developer
downloaded. Hard to understand? Apparently.

> > GNA: https://gna.org/forum/forum.php?forum_id=731
> > "Signed files that could not be verified will be moved in
> > subdirectories named /maybe-corrupted."
> >
> > GNA FAQ:
> > https://gna.org/faq/export_html.php?group_id=101#Download_Server_--_How_can_I_certify_or_check_the_authenticity_of_stored_files.txt
> > "To check the authenticity of a file, one of the best tools currently
> > available is GPG. We will not describe here what is GnuPG and how it
> > works: if you are looking for that information, check the GnuPG
> > documentation."
>
> I don't think we learned anything new here.

Sorry, I copied the wrong snippet:
"If it says the signature is correct, the authenticity of the file is
confirmed. Indeed, the signature should belong to a member of the
project."

Good thing me signing this didn't mean that I'd audited my e-mail to
make sure it was all correct, only that I did indeed send it as-is.

> > SaMBa: http://us2.samba.org/samba/download/
> > "The Samba distribution GPG public key can be used to verify that
> > current releases have not been tampered with."
>
> Exactly. How do I know that? I'm not a contributor to the Samba
> project. I'm not
> reading their source code commits list. But why do you think it means
> "tampered
> in transfer" as ooposed to just "tampered with"? The difference is in the fact
> that not just any key holder can sign a Samba tarball, but a developer Samba
> project trusts to do that. There's a difference.

You can use the vendor-sig from SaMBa to verify the tarball in that
case. You don't need to sign anything.

They said "tampered with", not "tampered in transfer"...meaning that,
if your GPG check passes the tarball has not been changed from the one
the SaMBa team posted for you to use.

> > Linux Security: http://linsec.ca/security_policy.php
> > "When you are installing software on your system(s), verify that it
> > hasn't been tampered with. Most authors provide md5sums for downloaded
> > source packages, and many are creating detached GPG signatures for
>
> Authors. Not distributors.

They're using authors as one example, not the only example.

> > software. Verification of software packages prevent problems like
> > trojaned openssh tarballs (not meaning to pick on the OpenSSH team
> > here, merely illustrating that critical software can be trojaned). One
> > should always attempt to verify distributed files via some means of
> > authentication. If you download RPM packages, check to make sure the
> > md5 and/or GPG signatures are intact. Auditing source code would be a
> > great thing to do, but realistically, this likely won't happen unless
> > you have excessive resources and/or a lot of spare time on your
> > hands."
>
> > Note that the integirty of the file is all that GPG is being used for,
> > guaranteeing that the file you downloaded is the one they meant you to
> > have. They are /not/ guaranteeing that the file is free from bad code,
> > malicious intent, etc.
>
> Really? Only integrity? Somehow I didn't notice that. It's not written
> in any of
> the samples above. It's not implied either.

You apparently didn't read the examples then. Perhaps you should have
read the example that this is under.

> > Also note that the last one explicitly states that auditing source
> > code would be nice, but isn't likely nor even guaranteed.
>
> That's the reason not to sign the stuff that's not coming from you.
> That's why I
> proposed signing spells.

Unnecessary obfuscation and an apparent misunderstanding of the
possible uses of GPG.

> > I can go look up more if you want. I don't see how you can be saying
> > that using GPG as we're intending, and as the above + world also uses
> > it, is incorrect and against whatever perceived knowledge of how GPG
> > is to be used that you have.
>
> Terminology continues to be pervasive in these arguments. Feel free to comb
> through a bugtraq archive to find out what hoops people have to jump
> through in
> order to send a vulnerability report to CERT. Do you think CERT is giving them
> all that trouble just to make sure the information is not altered in transit?
> They'd have used SSL for that.

You're the only one playing with terminology, misunderstanding
examples, and not even reading the examples but still using them as an
argument.

> So, tell me the decision. I'm waiting.

We still have Arwed and Thomas to hear from for the leads, and not
many developers have piped in yet, though in the end it's up to the
Leads, which is why they were elected.

- -sandalle

- --
Eric Sandall                     |  Source Mage GNU/Linux Developer
eric AT sandall.us                  |  http://www.sourcemage.org/
http://eric.sandall.us/          |  SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/  #196285  |  http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDFNpXHXt9dKjv3WERAmPOAJ9PUs/YqDa1ZodRBMdK3dqVpq2zOgCgjAS6
onpcwuXb/TP5ldbn0pfa0ik=
=+Bbk
-----END PGP SIGNATURE-----