Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Compromise on signatures

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
  • Cc: SM-Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Compromise on signatures
  • Date: Tue, 30 Aug 2005 15:14:45 -0700 (PDT)

-----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-----




Archive powered by MHonArc 2.6.24.

Top of Page