sm-discuss AT lists.ibiblio.org
Subject: Public SourceMage Discussion List
List archive
Re: [SM-Discuss] Clarifications on GPG signing of source tarballs
- From: Eric Sandall <eric AT sandall.us>
- To: "Sergey A. Lipnevich" <sergey AT optimaltec.com>
- Cc: sm-discuss AT lists.ibiblio.org
- Subject: Re: [SM-Discuss] Clarifications on GPG signing of source tarballs
- Date: Wed, 17 Aug 2005 10:05:28 -0700 (PDT)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 17 Aug 2005, Sergey A. Lipnevich wrote:
Hi All,
This is a request for comments after the discussion started here:
https://lists.ibiblio.org/sympa/arc/sm-discuss/2005-August/011831.html.
Some of the spell I created started being signed by other SMGL
maintainers. I'd like clarifications on such signatures, as opposed to
ones coming from upstream. What do I, or any maintainer without a
signature, do if I want to upgrade them to new version? I suppose I can
either get the key and get it signed, or not.
Get a key[0] so you can sign, have the prior guru (or another with a
key) verify the tarball and sign for you, or revert to md5sum/sha1.
In case I get the key, I'd gladly sign a *spell*, but I'm reluctant to
sign a *source package* coming from its author(s). I don't trust any of
the upstream package maintainers who don't sign tarballs themselves.
It's not clear how I can make sure their packages are safe, but it's
obvious that amount of work to make this happen it pretty high. I look
at it this way: by signing a package from upstream, I implicitly give my
trust to somebody I don't know. Would you consider signing a GPG key for
somebody you don't know? It's the same question.
Depends on how you look at it. The original reason for going to GPG
signing was so that we don't have to care about what algorithm
(md5sum, sha1, etc.) we use as we're using GPG, which can change
algorithms when new/better come out without us having to redo all of
the packages.
If you're looking at this as you saying, "I guarantee that this
tarball is 100% safe, has no trojans, viruses, or the like", then
that's a bit farther than we have the resources to go.
A middle ground would be saying, "I guarantee that this is the tarball
that the package author intended you to have". This would not be too
difficult (a hopefully quick e-mail exchange with the author or using
any of the other methods described in the post mentioned above) to
verify the tarball you're about to sign is the one the author
intended. Then all we're saying is that, yes, if the GPG check passes
you're getting the same tarball that the author intended and it hasn't
been messed with by anyone.
I believe the last one is as far as we'll go with verification, at
least until we have masses of sla^H^H^Hgurus to do source code
auditing for us.
We're not saying that we trust the authors to not have their package
run `rm -rf /`, what we're trying to give the users is authentication
that says 'this tarball is what the guru installed' and/or 'this
tarball is what the author intended you to have, without
modification'.
Quick summary of the above:
GPG checking can be used for either of the following:
1) Better replacement for picking a hash (md5sum/sha1/etc.)
2) Verification that the tarball a user is about to install is the
same as the package's author intended the user to use.
#2 would be the ideal use of GPG, but #1 is also acceptable and is/was
the original reason we switched to GPG.
The other alternative is to not get a key for myself. Am I allowed to
convert a spell with SMGL maintainer signature back to MD5- or
SHA-hashed source tarball when I upgrade it? If no, I come back to trust
issue above. If yes, what's the point of using those signatures?
You can use whichever method you want, but GPG checking (see above) is
preferred.
Ultimately, it comes down to the whether we require all maintainers to
have GPG keys before they can work on grimoires, so this question must
be addressed at a very high level of SMGL policies.
Technically they should all have a GPG key and have it listed and
updated on our Keysigning page[0], but not all do. This is supposed to
be the 'only' method for account information to be exchanged. ;)
Finally, if I have to get a GPG key, how do I get it signed? I know
there's nobody close to NYC contributing to SMGL, at least I think so.
Rutgers University nearby has an LUG, but I've never tried contacting
them. What do people do in this case?
I've added a link to the Keysigning page[0] for the GPG Keysigning
Party HOWTO[1]. We can do timed responses in #sourcemage-keysigning
for some verification (e.g. "hey b3|smgl, send me an e-mail to
sandalle AT sourcemage.org with a list of people who're in this channel",
signed by your new key), then I can reply to that e-mail (making sure
it goes to your 'regular' address) asking a question that you reply to
in IRC. More methods can be used for stronger verification if wanted.
- -sandalle
[0] http://www.sourcemage.org/security-keysigning
[1] http://www.cryptnet.net/fdp/crypto/gpg-party.html
- --
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)
iD8DBQFDA25cHXt9dKjv3WERAquSAJ9KSLlf35SsbadZ3kTqS/ss4UsoMQCfRvZe
SzvhMCwiqwjRBEvZWgYqdT4=
=XJaH
-----END PGP SIGNATURE-----
-
[SM-Discuss] Clarifications on GPG signing of source tarballs,
Sergey A. Lipnevich, 08/17/2005
- Re: [SM-Discuss] Clarifications on GPG signing of source tarballs, Jeremy Blosser (emrys), 08/17/2005
-
Re: [SM-Discuss] Clarifications on GPG signing of source tarballs,
Eric Sandall, 08/17/2005
-
Re: [SM-Discuss] Clarifications on GPG signing of source tarballs,
Seth Alan Woolley, 08/17/2005
- Re: [SM-Discuss] Clarifications on GPG signing of source tarballs, Jeremy Kolb, 08/17/2005
-
Re: [SM-Discuss] Clarifications on GPG signing of source tarballs,
Seth Alan Woolley, 08/17/2005
- Re: [SM-Discuss] Clarifications on GPG signing of source tarballs, Seth Alan Woolley, 08/17/2005
Archive powered by MHonArc 2.6.24.