nodata wrote:

...

A recent scam involving fake updates to Fedora has highlighted the lack of signed RPMs for Fedora Core.

What do you mean?

| [angenenr@localhorst packages]$rpm -K samba-common-3.0.6-2.fc2.i386.rpm | samba-common-3.0.6-2.fc2.i386.rpm: (sha1) dsa sha1 md5 gpg OK

Fedora Core RPMs (as livna.org RPMs and fedora.us RPMs and dag's RPMs and freshrpm's RPMs) *are* cryptographically signed.

...

"All official updates for Red Hat products are digitally signed and should not be installed unless they are correctly signed and the signature is verified." -- http://www.redhat.com/security/

Look, it even says so in the advisory!

...

What does the list think about signed RPMs - are they unnecessary for a community project, or are they useful?

You're talking about rawhide?

| [angenenr@localhorst tmp]$rpm -v -K zsh-4.2.0-3.i386.rpm | zsh-4.2.0-3.i386.rpm: | Header V3 DSA signature: OK, key ID 4f2a6fd2 | Header SHA1 digest: OK (4bd8d06387d5c7175b60bf200fb84a229d79b7d4) | MD5 digest: OK (16cc40302ebfd42dc2bc1d7f47cd7ded) | V3 DSA signature: OK, key ID 4f2a6fd2

Seems to be signed also.

Ralph

fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list

Fedora Core test (rawhide) isn't signed.

Why?

Le mardi 26 octobre 2004 à 13:17 +0200, nodata a écrit :

Fedora Core test (rawhide) isn't signed.

Why?

Or : RHEL beta is signed. Why ?

I decide to not use mirrors for rawhide. /etc/yum.repos.d/fedora-devel.repo [development] name=Fedora Core $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/core/development/$basearc... enabled=1

Not as good as signed rpm.

Le mardi 26 octobre 2004 à 10:54 -0400, William Hooper a écrit :

Matias Féliciano said:

...

Le mardi 26 octobre 2004 à 13:17 +0200, nodata a écrit :

...

Fedora Core test (rawhide) isn't signed.

Why?

Or : RHEL beta is signed. Why ?

You are beating a dead horse.

A) Fedora Rawhide isn't RHEL. B) RHEL Betas move slowly (as an example, there have only been a perl update and an RPM update since the RHEL v4 Beta was released in September).

As Test Fedora, Beta RHEL is not for mission critical. As Test Fedora, Beta RHEL is for test propose. As Test Fedora, Beta RHEL is not a supported product. As Test Fedora, Beta RHEL is public. As Test Fedora, Beta RHEL is only composed with free software. As Test Fedora, Beta RHEL is free ($0).

C) RHEL Betas use RHN.

And rpms are signed. useless ?

D) Fedora Test releases (which are a better comparison to RHEL Beta releases) are signed.

And updates are not (contrary to RHEL Beta).

So, the question is not closed : Why all Beta RHEL packages are signed ?

Le mardi 26 octobre 2004 à 08:25 -0400, William Hooper a écrit :

nodata said:

...

A recent scam involving fake updates to Fedora has highlighted the lack of signed RPMs for Fedora Core.

How? Would it make you feel better if the fake updates had installed a signature first?

Impossible. gpg check is done _before_ installing the package.

Matias Féliciano said:

...

Le mardi 26 octobre 2004 à 08:25 -0400, William Hooper a écrit :

...

nodata said:

...

A recent scam involving fake updates to Fedora has highlighted the lack of signed RPMs for Fedora Core.

How? Would it make you feel better if the fake updates had installed a signature first?

Impossible. gpg check is done _before_ installing the package.

Very possible. The fake updates weren't directly an RPM, the instructions had you run a shell script.

Yes, but that's not really the point. The point is that the RPMs are not signed.

It's not really important how it came to be noticed that the RPMs were not signed (i.e. the announcement about the recent scam)

It's not really relevant either than RPMs can verify themselves. The whole point of my post was that there is no way to verify a rawhide RPM originated from Red Hat.

True, signing them would devalue the signing key, but NOT signing them devalues the RPMs even more because they cannot be automatically verified using a package manager.

-- William Hooper

-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list

Le jeudi 28 octobre 2004 à 12:34 -0400, Peter Jones a écrit :

On Thu, 2004-10-28 at 14:34 +0200, nodata wrote:

...

Yes, but that's not really the point. The point is that the RPMs are not signed.

It's not really important how it came to be noticed that the RPMs were not signed (i.e. the announcement about the recent scam)

It's not really relevant either than RPMs can verify themselves. The whole point of my post was that there is no way to verify a rawhide RPM originated from Red Hat.

True, signing them would devalue the signing key, but NOT signing them devalues the RPMs even more because they cannot be automatically verified using a package manager.

The question is still one of gains versus losses. I personally think we gain more by _not_ signing them. If we automatically sign them, we make it more convenient for people who don't want to use --nosig or whatnot on rawhide packages.

That's not a win.

That's not a loss.

In fact, it's a big loss. If the packages are automatically signed during the build process, the only thing the signature means is "it showed up in the queue of things to be signed". But if you see a signed package, the impression you get is that it is in some way "trusted". Of course, it isn't trusted. It's just got a signature that says "don't make the user type --nosig".

what is the loss ? If the package is signed you can install it with -- nosig or without --nosig. If the package is not signed you should use --nosig and definitely don't trust any mirrors at any moment.

So, what is the loss ?

If you _really_ want a way around that, change the update tools so you can mark a repo as being allowed to have unsigned packages.

This is a _real_ big loss.

If the problem you're trying to avoid is corruption or injection attacks on a repo, signing the packages still isn't the right answer

But i can't still see the loss.

-- sign the metadata on the repo, and then compare the packages to that, instead.

???? "createrepo --addsign ...." is better than "rpm --addsign *.rpm" ? Why ?

Then there's no misplaced trust on the package, as you'd get by signing it, but there is verification that it is the right package.

???? You mean I should not trust the right package ?

-- Peter

Le jeudi 28 octobre 2004 à 15:01 -0400, Jeff Spaleta a écrit :

On Thu, 28 Oct 2004 19:38:02 +0200, Matias Féliciano feliciano.matias@free.fr wrote:

...

???? "createrepo --addsign ...." is better than "rpm --addsign *.rpm" ? Why ?

...

Then there's no misplaced trust on the package, as you'd get by signing it, but there is verification that it is the right package.

???? You mean I should not trust the right package ?

Rawhide packages...by there very nature shouldn't be trusted.

Rawhide packages should be trusted as rawhide package. Without signature, what seems to be Rawhide package can be anything.

Rawhide packages may in no unspecified order: eat your children pollute your network eat your children destroy your data eat your chidren

The problem here is interpretation of what signing a package is meant to mean. You really really really want it to be used for something new, to imply a level of trust intermediate of what its beeen traditionally used for and no signing at all. The LOSS, in this case, is confusion as to what it means when a package is signed.

signed package, mean signed package. Go to the gnupg documentation if you want to learn more : http://www.gnupg.org/documentation/index.html

(snip)

On Thu, 2004-10-28 at 15:17 -0600, Rodolfo J. Paiz wrote:

experienced programmers such as Dave and Jeff [...]

s/Dave/Peter/

Sorry!

Le jeudi 28 octobre 2004 à 15:17 -0600, Rodolfo J. Paiz a écrit :

On Thu, 2004-10-28 at 22:14 +0200, Matias Féliciano wrote:

...

signed package, mean signed package. Go to the gnupg documentation if you want to learn more : http://www.gnupg.org/documentation/index.html

Matías,

Even though I believe you have some interesting points, pointing very experienced programmers such as Dave and Jeff to the GNUPG docs is downright insulting and (I would say) entirely inappropriate.

Sorry.

But I am tired with this mix of authentification, quality, rawhide mean "don't complain", trust own unsigned rawhide rpm but don't trust own unsigned rpm if it's not rawhide, ... arguments. In France, mixing things not really related, we call this "noyer le poisson" (I can't translate). Signed rpm is about authentification. Nothing else.

I will not advocate for signed rpm any more since it seems I am near the "only" one to care about.

*They* have a lot of credibility and have earned a reputation for expertise and objectivity in this community, as far as I can tell from my measly 10 years of participation in it. *You* do not have their level of credibility yet, and disrespect to someone who is giving your points serious thought and consideration is no way to get it.

Be nice.

I'll try :-)

-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-test-list

On Thu, 2004-10-28 at 17:44 -0600, Rodolfo J. Paiz wrote:

On Thu, 2004-10-28 at 23:40 +0200, Matias Féliciano wrote:

...

But I am tired with this mix of authentification, quality, rawhide mean "don't complain", trust own unsigned rawhide rpm but don't trust own unsigned rpm if it's not rawhide, ... arguments.

I think it's more of a question of attaching a different meaning to things. You see signing the Rawhide packages as a way to know that they were not altered on a mirror, such that you are sure of downloading the actual code produced by Red Hat. However, Peter and Jeff see signing the package as having the same value as your signature on a legal document: certification of something of value. As such, Fedora releases and updates (even beta releases) are signed, but Rawhide releases are not.

Both points of view make sense, but they attach different meanings to the concept of "signing" something.

My *interpretation* of what you wanted is that you would get exactly what you want by having people sign the metadata in the repository as was suggested earlier. You can then be certain that whatever is in the repo is exactly what it should be.

Now, how do we sign repo metadata?

So we (in a very much too broad sense of "we" ;-) are basically saying that we should replace a mechanism that worked well for years with another one that a) puts a burden on the people who "know what things mean", b) doesn't really solve the problem with people doing things they shouldn't do(*) and c) doesn't exist already? Great idea ;-).

(*): See another mail of me in this thread why assume this.

Nils

On Fri, 2004-10-29 at 11:06 -0600, Rodolfo J. Paiz wrote:

That being said, let me take your points one by one:

1. Replace something that worked well for years. What was the

mechanism previously that let me verify that the updated kernel RPM on Mirror X was a bit-identical copy of the one actually published by Red Hat? I know how to verify ISO's but know of nothing that verifies a package was not tampered with after being placed on a mirror.

This is an old snapshot of Rawhide but serves well nonetheless:

nils@gibraltar:/misc/scratch/rawhide/i386/Fedora/RPMS> rpm -K rpmdb-fedora-1.91-0.20040325.i386.rpm bash-2.05b-38.i386.rpm rpmdb-fedora-1.91-0.20040325.i386.rpm: sha1 md5 OK bash-2.05b-38.i386.rpm: (sha1) dsa sha1 md5 gpg OK

See? I can verify that the bash package is signed with one of the keys I have in the keyring. Granted that I can't see (here) which key it was signed with and we have no way where I can say how much I want to trust a key in terms of RPM -- I admit that RPM's notion of keys and trust is a little black and white, but it's better than nothing.

2. Puts a burden on people who know. Why? If a repo's metadata is

signed, isn't that just one more check up2date and yum can perform to

Sometimes up2date or yum aren't available (maybe because you botched your python installation) or you have only the packages on a USB stick an you have no net or a very slow network connection (where you wouldn't want to download the entire metadata which is MBs only to verify a 16K package) or whatever.

improve authentication of a package? Isn't that automatic? And can't someone also get it by hand if they choose? Besides, since you can always get the package *without* checking the metadata if you so choose with a simple "wget", what burden is put on these people?

I meant that you can get the package but you can't check its integrity without using yum or up2date which isn't always feasible. Today I can check that an individual package originates from the Red Hat build system, I don't want to lose this ability.

3. Doesn't stop people from doing things they shouldn't do. No

kidding... as I understood it, the idea of signing metadata had no "control" purposes in mind whatsoever. It was merely intended to be a way to know that the bits stored on server "A" were the same as those issued by the RHI buildsystem. How is this relevant?

Exactly this purpose is currently being fulfilled in 95% (some random number) of the packages by themselves being signed. Again my case is not contra repo metadata signing but pro individual package signing.

4. Doesn't exist already. So what's your point? Tell me that it's a

bad idea and explain why. But "doesn't exist yet" is a bloody silly argument.

My point was that RPM package signing exists now and I haven't seen a convincing argument in this entire discussion why this would be a bad thing. Not even on Rawhide packages. So I have my gripes with replacing individually signed packages with something that isn't there yet but still doesn't offer me the functionality I want. Especially when we can have both.

Seems to the unwashed masses here that signing repo metadata provides one benefit (knowing package A on server A is bit-identical to package A on server B) and has no real cost other than the addition of a new feature (which is even optional, since no one *has* to use it) to package managers like yum and up2date.

I see no downside. Since you do, can you provide more detail on what and why?

I see no downside in repo metadata signing either, it's a good thing actually. But it is not an argument on why packages shouldn't be signed individually.

Nils

On Fri, 2004-10-29 at 13:42 -0400, Elliot Lee wrote:

On Fri, 29 Oct 2004, Nils Philippsen wrote:

...

On Fri, 2004-10-29 at 11:06 -0600, Rodolfo J. Paiz wrote:

...

That being said, let me take your points one by one:

1. Replace something that worked well for years. What was the

mechanism previously that let me verify that the updated kernel RPM on Mirror X was a bit-identical copy of the one actually published by Red Hat? I know how to verify ISO's but know of nothing that verifies a package was not tampered with after being placed on a mirror.

This is an old snapshot of Rawhide but serves well nonetheless:

nils@gibraltar:/misc/scratch/rawhide/i386/Fedora/RPMS> rpm -K rpmdb-fedora-1.91-0.20040325.i386.rpm bash-2.05b-38.i386.rpm rpmdb-fedora-1.91-0.20040325.i386.rpm: sha1 md5 OK bash-2.05b-38.i386.rpm: (sha1) dsa sha1 md5 gpg OK

See? I can verify that the bash package is signed with one of the keys I have in the keyring. Granted that I can't see (here) which key it was signed with

Actually, you can, using 'rpm -Kv'. :-)

Deep inside I knew you could ;-).

Nils

On Fri, 2004-10-29 at 14:06 -0400, Paul Iadonisi wrote:

On Fri, 2004-10-29 at 19:37 +0200, Nils Philippsen wrote:

...

On Fri, 2004-10-29 at 11:06 -0600, Rodolfo J. Paiz wrote:

[snip]

...

...

I see no downside. Since you do, can you provide more detail on what and why?

I see no downside in repo metadata signing either, it's a good thing actually. But it is not an argument on why packages shouldn't be signed individually.

Um...did I miss something? I didn't see anyone suggest *replacing* package signing with repo metadata signing. It's just an added measure to help ensure that what is on the mirrors is what is on the official Red Hat repo. Granted, you still need yum or up2date to use that information, but it's still a net gain. In particular for when some packages don't get signed, which seems to be what this thread is about (today, anyhow ;-)). At least, I sure *hope* no one was suggesting foregoing package signing. Cuz that would be bad. :-)

Umm yeah. Some people were proposing that Rawhide packages should not be signed at all. I myself think this is a bad idea and that all packages, regardless of their quality, should be signed. Hey even more so with bad packages I want to know who's responsible ;-).

Nils

On Fri, 2004-10-29 at 20:15 +0200, Nils Philippsen wrote:

On Fri, 2004-10-29 at 14:06 -0400, Paul Iadonisi wrote:

...

On Fri, 2004-10-29 at 19:37 +0200, Nils Philippsen wrote:

...

On Fri, 2004-10-29 at 11:06 -0600, Rodolfo J. Paiz wrote:

[snip]

...

...

I see no downside. Since you do, can you provide more detail on what and why?

I see no downside in repo metadata signing either, it's a good thing actually. But it is not an argument on why packages shouldn't be signed individually.

Um...did I miss something? I didn't see anyone suggest *replacing* package signing with repo metadata signing. It's just an added measure to help ensure that what is on the mirrors is what is on the official Red Hat repo. Granted, you still need yum or up2date to use that information, but it's still a net gain. In particular for when some packages don't get signed, which seems to be what this thread is about (today, anyhow ;-)). At least, I sure *hope* no one was suggesting foregoing package signing. Cuz that would be bad. :-)

Umm yeah. Some people were proposing that Rawhide packages should not be signed at all. I myself think this is a bad idea and that all packages, regardless of their quality, should be signed. Hey even more so with bad packages I want to know who's responsible ;-).

No, nobody is "proposing that Rawhide packages shouldn't be signed at all". That's pure spin. They are not currently signed, and I'm arguing against the proposal that they *should* be.

I'm not arguing against the idea that it should be possible to strongly verify the source of the packages. I am arguing against the desire to use the same mechanism as we use for saying that we think a package is safe, either from innocent corruption or intentional tampering at any part of the packaging process.

A signature on a package announces a degree of trust that somebody has on the payload of that package, and that the headers belong with that payload. That's not what is being asked for when people ask for rawhide packages to be signed. What is being requested is a method to verify that the package is truly from a known source. That, and that alone, is what is request at hand.

While our current signing method does guarantee the source of the package, that is not all it guarantees. Fedora and Red Hat (and arguably Seth ;) are in a unique position regarding policy around RPM, and because of this we must be very careful. If, for any repository, we use our current signature method to signify *only* that the repository is the source of the package, then we necessarily give up all other meanings of it for all other repositories.

All of that being said, this is not an insurmountable problem. In fact, there are fairly straightforward methods to gain this verification, although they are not necessarily trivial by any stretch of the imagination.

But first, we have to be clear about what we've got right now, because it's not completely obvious. Usually we see a package as:

1) payload 2) headers, which contain checksums on header and payload data 3) a signature on #2.

But a better way of considering these parts is this:

1) payload 2) headers, which includes checksums on header and payload data 3) a certificate, which is completely implied, derived from the checksum data in the headers, and the header entries specifying the source of the package. 4) a signature on #3.

Right now, that certificate conveys both trust that the checksums are correct, and trust on the source of the package. The important part of these meanings are in the eye of the beholder. We cannot say that a signature means only one thing without permanently giving up the other.

So what we need if we want to imply only the source is another signed certificate. This can either be in the package, as our current rather ethereal certificate is, or it can be separate. It still has to include some way to verify which package you're talking about, and it still needs to have a signature.

The easy way to get this is to generate a metadata file when we push rawhide out, and to give it a certificate with a signature.

There is still some complication, though, which is that package fetching utilities such as yum and up2date would need to be taught to only check that the source is correct in situations where that's all they care about.

Le vendredi 29 octobre 2004 à 12:45 -0600, Rodolfo J. Paiz a écrit :

Matías is vehemently pro signing *every* package

Yes. But I never said that a signed repository is a bad solution :-)

Signing repository has its benefit. Signing every packages has its benefit.

But I don't think it's easer to sign a repository than all the packages.

For signing a repository, one command line would be used (I suppose) : - gpg --sign ... OR createrepo --addsign

For signing all packages, one command line would be used : - rpm --addsign <list of rpm package>

If Red Hat can use one of these methods, they can easily do both (It's seems).

Le vendredi 29 octobre 2004 à 16:33 -0600, Rodolfo J. Paiz a écrit :

On Fri, 2004-10-29 at 22:56 +0200, Matias Féliciano wrote:

...

But I don't think it's easer to sign a repository than all the packages.

For signing a repository, one command line would be used [...] For signing all packages, one command line would be used [...]

If Red Hat can use one of these methods, they can easily do both (It's seems).

Your logic is seriously flawed. The repository is created once, and updated on a specific and regular schedule. The entire repository metadata is signed at one time and in a predictable fashion.

Precisely the problem which has been pointed out about signing every package is that there is no one around at the particular time when a few packages are finally ready, and it is those that do not get signed. But all packages are finished at different times, so it is impractical to suggest that all packages can be signed together with a single command.

Since rawhide have some unsigned packages I like to know which package is not signed and I sign them with my key (so yum always have "gpgcheck=1") : I mirror rawhide in the i386 directory with rsync, and then I sign package that miss gpg. Note, I don't sign (that is, change) any package in i386 directory (rsync does not like this).

add_sign.sh (an ugly personal script) : #!/bin/bash cd i386 # copy newly unsigned package to i386_s and sign them. find *.rpm -not -exec test -f ../i386_s/{} ; -print0 | xargs -0 rpm -K | grep "md5 OK$" | sed -n -e "s/:.*$//p" | xargs -i bash -c "cp {} ../i386_s ; echo {}" | ( cd ../i386_s/ ; xargs rpm --addsign ) # remove old package in i386_s cd ../i386_s find *.rpm -not -exec test -f ../i386/{} ; -print0 | xargs -0 rm -f # add missing symbolic links from i386_s to i386 cd ../i386 find *.rpm -not -exec test -f ../i386_s/{} ; -printf "../i386/%f\0" | xargs -0 ln -s -v --target-directory=../i386_s

In i386_s, I have something like : lrwxrwxrwx 1 admin admin 31 oct 22 16:22 indent-2.2.9-6.i386.rpm -> ../i386/indent-2.2.9-6.i386.rpm lrwxrwxrwx 1 admin admin 33 oct 22 16:22 inews-2.3.5-11.1.i386.rpm -> ../i386/inews-2.3.5-11.1.i386.rpm lrwxrwxrwx 1 admin admin 27 oct 22 16:22 info-4.7-5.i386.rpm -> ../i386/info-4.7-5.i386.rpm -rw-rw-r-- 1 admin admin 1078855 oct 28 18:46 initscripts-7.93.2-1.i386.rpm lrwxrwxrwx 1 admin admin 31 oct 22 16:22 inn-2.3.5-11.1.i386.rpm -> ../i386/inn-2.3.5-11.1.i386.rpm lrwxrwxrwx 1 admin admin 37 oct 22 16:22 inn-devel-2.3.5-11.1.i386.rpm -> ../i386/inn-devel-2.3.5-11.1.i386.rpm

Then I run createrepo in this directory, I use ONE "rpm --addsign".

Since, as you pointed, the repository is signed ONE time (per day :-)), at the moment when the repository is ready to be signed, ALL unsigned packages are available (I mean, ready to be signed).

Le vendredi 29 octobre 2004 à 21:59 -0700, Nifty Hat Mitch a écrit :

The comment about rsync is interesting.

The question may be: How does rsync like a package being signed or better yet resigned at some later time?

As I understand it the gpg signature is a modest structure and resigning an rpm does not so badly mess up a file that rsync cannot optimize the change as long as the keys have the same length.

To test I picked on something big and network rude to change and test. Thus...

The problem is that all changed rpm would be check again at the next invocation of rsync. When there is about 1 Go of unsigned rpm, this mean that the client _and_ the server should read 1 Go of data (even if a small part of the data have changed). The mirror don't like this.

On Oct 30, 2004, "Rodolfo J. Paiz" rpaiz@simpaticus.com wrote:

I'm going to assume that you mean "1GB" (as in gigabyte) since I have no idea what a "Go" is.

Giga-octet. You know, bytes don't have to have 8 bits. French is more precise than English, at least in this regard.

That being said, one of the beauties of rsync is that it will *not* need to reread the entire file

Not quite. Both ends will have to reread the entire file, possibly even twice. They won't have to *transfer* the entire file, but for a mirror, disk bandwidth may also be a critical resource. Still, it would be no different from the current situation, in which a package is first published unsigned, and some time next day (or a few days later :-) a signature is stapled to it.

On Sat, 2004-10-30 at 21:31 +0200, Matias Féliciano wrote:

Small penalty transfer. But reading 1 Go^UGB of data is a big penalty.

Point taken. On the other hand, how often is the batch of unsigned packages that large? Does that happen often?

Cheers,

On Sat, 2004-10-30 at 01:11 +0200, Matias Féliciano wrote:

Since rawhide have some unsigned packages I like to know which package is not signed and I sign them with my key (so yum always have "gpgcheck=1") : I mirror rawhide in the i386 directory with rsync, and then I sign package that miss gpg. Note, I don't sign (that is, change) any package in i386 directory (rsync does not like this).

When somebody organizes a man-in-the-middle attack between you and whichever site you rsync rawhide from , you sign the packages anyway. Can you see how this is a big problem?

On Fri, 2004-10-29 at 12:45 -0600, Rodolfo J. Paiz wrote:

On Fri, 2004-10-29 at 19:37 +0200, Nils Philippsen wrote:

...

I see no downside in repo metadata signing either, it's a good thing actually. But it is not an argument on why packages shouldn't be signed individually.

Sigh... backing up a few steps for historical clarification:

Matías argued that, because *some* Rawhide packages are not signed, one does not have for those packages *any* ability to see that what is on a mirror is in fact exactly what came out of the Red Hat buildsystem. He argued pro signing of all Rawhide packages.

I'm with Matías here.

Others argued that this has either no value or negative value. A debate ensued as to whether passwordless keys would be better than nothing or worse than nothing.

I wasn't pro password-less keys, but pro some kind of automatic signing of all packages or to be more precise pro signing of all packages that get pushed (which implies automatic signing as they're pushed automatically). This doesn't imply leaving the keys unguarded or password-less because our build system also isn't unrestricted, i.e. not everyone can build packages which means that not everyone can get something signed with that key. When I build a package in the build system, the one signing the package later will trust me that I didn't do something nasty with it, so the result is practically the same whether signing happens manually or automated, only that in the latter case no package is forgotten. Especially since the people who operate the build system are the same that do the signing ;-).

Someone suggested that, for those Rawhide packages which were not signed, one possible way to get that benefit of knowing that package XYZ on Server A is bit-identical to the one on the main Rawhide server was to sign the repo metadata. It was suggested that this would provide an additional benefit to the rest of the world, at no real downside.

Still someone or something would have to sign at the time of pushing, whether this means signing packages or repo metadata and whether this is done manually or automatically is largely irrelevant IMO.

I really liked the idea and said basically that if this has good benefit and no real downside, then how do we get it done?

OK, sorry for getting you wrong there.

You came on scene and started arguing that it was a Bad Thing which would destroy the world as we know it. ;-) We now realize that you are not "contra repo signing" but rather "pro package signing".

I was getting misunderstood as well as some other people -- now that we can agree on this, how do we move on?

So welcome to the club. I am also pro package signing, but some Rawhide packages are not signed and at least repo signing helps provide some benefit, and I like that benefit. Matías is vehemently pro signing *every* package, and some people have responded that they either don't want to sign all Rawhide packages, or perhaps even don't want to sign any Rawhide packages. I'll leave exact interpretations to you when you read through the archived thread.

As outlined above, the process of signing repo metadata and the process of signing individual packages isn't that much different in that it needs someone or -thing to do the signing. I think signing repo metadata is good to augment the signing of packages in that someone certifies a specific set of packages, which is a benefit if you e.g. think of some bad guy trying to inject a (signed) iptables package into a mirror repository that by whatever problem wouldn't work together with the kernel already in there.

Now... the whole point of this thread is now to:

1. Argue that all packages should be signed, even all Rawhide. There

appear to be strong feelings either way.

I think it can be done without sacrificing any of the security we already have. Probably we should be thinking about using very short- lived keys for that, along with teaching RPM how to respect EOL dates for these keys as well as signed keys so that we can e.g. change the Rawhide key every few days, having it (manually) signed with a "master" key and have this key in a well defined place where tools and/or users could grab it once a new one is out and being sure that by SSL- certificate and GPG signing that this is the real key.

On the other hand the argument that we should use the presence of a (Red Hat) signature as a measure of quality is rather moot in my eyes as I have had a number of my packages out there with great difference in quality and all of them signed, even with a non-Rawhide key ;-). We have to teach the people who think about the signature being a sign of quality instead of origin about its real meaning, we shouldn't conform to their ill views.

2. In context, it also appeared that repo signing could also be

implemented as an *additional* measure that would provide some good benefits. I have not seen any arguments against that other than yours.

What do you think of those two thoughts?

Mine wasn't an argument against repo metadata signing -- some people (too lazy to check who ;-) sounded to me like they would want to replace package signing with repo metadata signing.

Have a nice Sunday, Nils

On Sun, 2004-10-31 at 14:55 +0100, Matias Féliciano wrote:

Le dimanche 31 octobre 2004 à 13:35 +0100, Nils Philippsen a écrit :

...

On Fri, 2004-10-29 at 12:45 -0600, Rodolfo J. Paiz wrote: As outlined above, the process of signing repo metadata and the process of signing individual packages isn't that much different in that it needs someone or -thing to do the signing. I think signing repo metadata is good to augment the signing of packages in that someone certifies a specific set of packages, which is a benefit if you e.g. think of some bad guy trying to inject a (signed) iptables package into a mirror repository that by whatever problem wouldn't work together with the kernel already in there.

A "Conflict" field in the rpm is a better solution.

A "Conflict" field is only a reactive solution, i.e. you need to know about the issue (and those with malicious intent won't tell you about it ;-). Signing repo metadata is a proactive measure that might prevent such scenarios even in the case when we don't know about such a situation.

...

On the other hand the argument that we should use the presence of a (Red Hat) signature as a measure of quality is rather moot in my eyes as I have had a number of my packages out there with great difference in quality and all of them signed, even with a non-Rawhide key ;-). We have to teach the people who think about the signature being a sign of quality instead of origin about its real meaning, we shouldn't conform to their ill views.

Interesting. There is _nothing_ that describe Test release and Rawhide. Nothing. Red Hat did a brilliant job in describing what Fedora is (section About of fedora.redhat.com). Red Hat may describe Test release and Rawhide. These informations may also be in the fedora-release package.

Here's my 2p:

Rawhide is constantly in flux and its quality is variant -- anything between "quite good" and "eats your hamster" is possible.

A test release is a snapshot of Rawhide where we try to not break too many things before, i.e. we usually have a freeze before a test release where the release managers permit fixes and only controlled new features between the freeze and release of the snapshot.

Nils

On Thu, 2004-10-28 at 12:34 -0400, Peter Jones wrote:

On Thu, 2004-10-28 at 14:34 +0200, nodata wrote:

...

Yes, but that's not really the point. The point is that the RPMs are not signed.

It's not really important how it came to be noticed that the RPMs were not signed (i.e. the announcement about the recent scam)

It's not really relevant either than RPMs can verify themselves. The whole point of my post was that there is no way to verify a rawhide RPM originated from Red Hat.

True, signing them would devalue the signing key, but NOT signing them devalues the RPMs even more because they cannot be automatically verified using a package manager.

The question is still one of gains versus losses. I personally think we gain more by _not_ signing them. If we automatically sign them, we make it more convenient for people who don't want to use --nosig or whatnot on rawhide packages.

If we don't sign packages we make it basically impossible for people to check where a specific package comes from. There is nothing else that a signature on a package says.

That's not a win. In fact, it's a big loss. If the packages are automatically signed during the build process, the only thing the signature means is "it showed up in the queue of things to be signed". But if you see a signed package, the impression you get is that it is in some way "trusted". Of course, it isn't trusted. It's just got a signature that says "don't make the user type --nosig".

That's a misinterpretation of the signature on the package. We shouldn't sign or not sign packages based on how people could misconceive what such a signature means. We should sign packages so people can verify that these packages are actually from us and haven't been tampered with in the meantime.

I mean, I have the privilege of sucking the packages directly from the build system so I can be fairly sure that these packages are the real ones (besides getting them first haha!). If I wouldn't have this access, I would be either forced to use certain tools that could cope with signed repository metadata or download directly from download.fedora.redhat.com. Both alternatives aren't very appealing to me.

If you _really_ want a way around that, change the update tools so you can mark a repo as being allowed to have unsigned packages.

If the problem you're trying to avoid is corruption or injection attacks on a repo, signing the packages still isn't the right answer -- sign the metadata on the repo, and then compare the packages to that, instead. Then there's no misplaced trust on the package, as you'd get by signing it, but there is verification that it is the right package.

I still don't see how signing a package makes it more trustworthy than signing the repo metadata. Signing a package gives me some amount of trust in its origin, not its quality or whatever.

Nils

John Burton said: [snip]

As far as signing packages vs. signing meta-data... Digital signatures are like real signatures, you want to make sure they are actually attached to what you are signing.

[snip]

IIRC the discussion was that signed meta-data would have the signatures attached to the MD5sums of the packages. The MD5sums of the download could then be checked against the meta-data, verifying that the package is the same as the package used to create the meta-data.

On Fri, 2004-10-29 at 09:18 -0400, William Hooper wrote:

John Burton said: [snip]

...

As far as signing packages vs. signing meta-data... Digital signatures are like real signatures, you want to make sure they are actually attached to what you are signing.

[snip]

IIRC the discussion was that signed meta-data would have the signatures attached to the MD5sums of the packages. The MD5sums of the download could then be checked against the meta-data, verifying that the package is the same as the package used to create the meta-data.

This still forces me to use special tools like up2date and yum to access the packages if I want to verify their origins.

Nils

Le vendredi 29 octobre 2004 à 09:48 -0400, seth vidal a écrit :

...

This still forces me to use special tools like up2date and yum to access the packages if I want to verify their origins.

Is this really all that big of a deal?

And apt ?

On Fri, 29 Oct 2004 15:36:47 +0200, Nils Philippsen nphilipp@redhat.com wrote:

This still forces me to use special tools like up2date and yum to access the packages if I want to verify their origins.

actually...no.

you can grab the signed metadata with the md5sums, check the sig on that. and then do a md5sum check comparing the md5sum values in the metadata and the package. You can do the md5sum check by hand. This isn't much different than the situation with the isos. How do you verify you are using the correct isos? you check the md5sums against an md5sum list. How do you check the validity of the md5sum list? You check the md5sum list signature.

You might argue it would be a good idea if there was a signed flat md5sum list for all packages as well as the xml metadata, so the md5sum command could use it. And then I'll tell you, you need to accept the inevitable future of xml for all possible human communication adopted by unanimous United Nations resolution, and you should fix md5sum to parse xml structure files for md5sum sigs :->

And I really really really don't want to encourage people to use rawhide packages randomly from something like an online rpm warehouse. I don't want misinformed people, being able to pick up an individual rawhide package, see that its signed, and use the fact that there is a verifable signature as an easy excuse to assume its totally okay to install. This sort of crap happens a lot with unsigned rawhide, and I don't want people who misunderstand what a signature really means to feel more comfortable installing rawhide packages when they should not be. There is a gap between, the technical definition of what signing a package means, and common perception of what a signed package means. My concerns is not for people like yourself, who understand that a rawhide key doesnt mean anything beyond 'this package was built on the automated rawhide build system." My concern is for the people, the much larger group of people, who will misinterpret the level of trust associated with ANY key and will be that much more inclined to install a random rawhide package they happen to find outside of a rawhide mirror, without thinking about it at all. It doesn't help that as of now rpm key importation can't handle signed keys, and thus web-of-trust metrics can't be used natively to produce a metric of trust of keys. How do you implement verification for those people who understand what it means, without giving a false sense of security and trust for those people who are misinformed about the process who end up using the rawhide packages out of their original context? I say you sign the metadata and have the informed people use the package metadata for verification.

Can rawhide packages be automatically signed... of course Does autosigning help the intended, well informed, audience of the rawhide packages... yes Does autosigning hurt the unintended, un-informed or mis-informed audience... i think it does.

-jef

Jeff Spaleta wrote:

Can rawhide packages be automatically signed... of course Does autosigning help the intended, well informed, audience of the rawhide packages... yes Does autosigning hurt the unintended, un-informed or mis-informed audience... i think it does.

So you're suggesting that the use of signed packages should be limited by some "least common denominator" of ignorant users? I suspect that if you broadly adopt that principle, you won't be real happy with the results.

On Mon, 1 Nov 2004, Peter Jones wrote:

On Fri, 2004-10-29 at 09:44 -0500, Ian Pilcher wrote:

...

Jeff Spaleta wrote:

...

Can rawhide packages be automatically signed... of course Does autosigning help the intended, well informed, audience of the rawhide packages... yes Does autosigning hurt the unintended, un-informed or mis-informed audience... i think it does.

So you're suggesting that the use of signed packages should be limited by some "least common denominator" of ignorant users? I suspect that if you broadly adopt that principle, you won't be real happy with the results.

No, this is the wrong problem to discuss. The problem isn't that the users are ignorant. The problem is that we've systematically taught them what to expect a signature means, and we're going back and saying that sometimes -- only sometimes -- it only means part of that.

That's a serious flaw, and it's one we must address before we consider implementing any sort of automatic signatures. The way to do so is to separate the task of verifying the source (or even the chain of sources, if there are mirrors of mirrors) from that of verifying trust of the contents.

Are you saying - currently when a package is gpg-signed by a person - he/she actually goes through a manual process of verifying the following?

- source is not tampered (including the intial .tar.gz, patches, .spec files) - binary is not tampered - source -> binary process didn't introduce 'ANY' tampering?

If not - I don't see any big change - as far as user perception goes on gpg-sigining on build system.

For us users there is no confusion: - 'rawhide-key' is different from 'redhat-key' - so there is no confusion here. - 'gpg' singed packages doesn't => stability (aka rawhide can always eat data) - so no confusion here..

Satish

On Mon, 2004-11-01 at 12:24 -0600, Satish Balay wrote:

Are you saying - currently when a package is gpg-signed by a person - he/she actually goes through a manual process of verifying the following?

• source is not tampered (including the intial .tar.gz, patches, .spec files)
• binary is not tampered
• source -> binary process didn't introduce 'ANY' tampering?

I'm saying that when we release signed packages as Fedora or as Red Hat, we are acknowledging that we intend for all of these to be the case, and that we believe they are. That is to say that when we distribute a signed package it generally holds true, and is assumed to be true, that:

- we've not included malicious code from the upstream - we don't think there are negative legal ramifications of us distributing that package in the distro - the source has not been maliciously tampered while retrieving it from the upstream source - the packaging itself is reasonable and will not harm your system when used appropriately - the process of compiling it did not introduce harmful changes which should have or could have been known ahead of time (that is, that the build environment can be trusted not to introduce problems) - for Fedora Core packages, the packages are free software - the packages are really from us (the signer)

This is at least the case when we release a distro, a release candidate, or a test release in which the packages are signed. And in the very minor variations where one of these points isn't the case, the perception is still that they all are. That's what's important here, not the intent. If the intent isn't perfectly clear when looking at the data and the tools, then it doesn't make any difference to our users.

I further stipulate that unless there is actually some observable, immutable data to signify that a signature means only that the source has been verified, many users will assume that any signature represents _all_ of these things, and they are justified in this assumption.

The problem that people are hoping to address is inconvenience of testing rawhide packages because they are not signed. Right now, package update tools have no option but to check both if the package data is correct and if the package is the one intended to be in the repo.

Update tool authors resist making signature checking configurable on a per-repo basis, which would alleviate the strain but reduce the overall utility of the tools. At the same time, users of rawhide and update tools really only care that the package is from the repo, not anything else. So the best answer, IMO, is to make it so that you can say "this is the right package" without all of the other implications, and then to change the update tools so that you *can* say "for this repo, I only care that the package is really from the repo". We don't need to check our traditional "package signature" per se; we need to check only that the package is the intended one.

If not - I don't see any big change - as far as user perception goes on gpg-sigining on build system.

For us users there is no confusion:

• 'rawhide-key' is different from 'redhat-key' - so there is no confusion here.

Make this work in a world where users draw from multiple, unrelated repositories. Some people (not very many) know that rawhide-key means it isn't for a production release. But Joe Foo's repositories have packages signed with joefookey1 and joefookey2. Which is which?

This is not viable.

• 'gpg' singed packages doesn't => stability (aka rawhide can always eat data) - so no confusion here..

The signature *sometimes* does imply that. If the only difference is the key, then there's really not any way to tell when.

On Mon, 1 Nov 2004, Peter Jones wrote:

On Mon, 2004-11-01 at 12:24 -0600, Satish Balay wrote:

...

Are you saying - currently when a package is gpg-signed by a person - he/she actually goes through a manual process of verifying the following?

• source is not tampered (including the intial .tar.gz, patches, .spec files)
• binary is not tampered
• source -> binary process didn't introduce 'ANY' tampering?

I'm saying that when we release signed packages as Fedora or as Red Hat, we are acknowledging that we intend for all of these to be the case, and that we believe they are. That is to say that when we distribute a signed package it generally holds true, and is assumed to be true, that:

• we've not included malicious code from the upstream
• we don't think there are negative legal ramifications of us distributing that package in the distro
• the source has not been maliciously tampered while retrieving it from the upstream source
• the packaging itself is reasonable and will not harm your system when used appropriately
• the process of compiling it did not introduce harmful changes which should have or could have been known ahead of time (that is, that the build environment can be trusted not to introduce problems)
• for Fedora Core packages, the packages are free software
• the packages are really from us (the signer)

This is at least the case when we release a distro, a release candidate, or a test release in which the packages are signed. And in the very minor variations where one of these points isn't the case, the perception is still that they all are. That's what's important here, not the intent. If the intent isn't perfectly clear when looking at the data and the tools, then it doesn't make any difference to our users.

Ok - I had to respond to this.

The correct thing to do is to document the above text for EACH gpg-key redhat uses. Saying the text is the SAME for ALL keys (hence can't sign rawhide) is wrong.

And you haven't specified what the gpg-singer does (the process he uses) to provide the above checks before signing.

I further stipulate that unless there is actually some observable, immutable data to signify that a signature means only that the source has been verified, many users will assume that any signature represents _all_ of these things, and they are justified in this assumption.

There will always be wrong assumption. The fix is documentation.

The problem that people are hoping to address is inconvenience of testing rawhide packages because they are not signed. Right now, package update tools have no option but to check both if the package data is correct and if the package is the one intended to be in the repo.

Update tool authors resist making signature checking configurable on a per-repo basis, which would alleviate the strain but reduce the overall utility of the tools.

yum has an option to do independent 'gpg-checks' on each repository. So this is not the problem.

At the same time, users of rawhide and update tools really only care that the package is from the repo, not anything else. So the best answer, IMO, is to make it so that you can say "this is the right package" without all of the other implications, and then to change the update tools so that you *can* say "for this repo, I only care that the package is really from the repo". We don't need to check our traditional "package signature" per se; we need to check only that

Now you are coming up with a complex system just to justfy using multiple gpg-keys with the exact same meaning.

I'll stop now. Satish

Ok - you & Seth seem to have a solution to the problem.

Still no good explanation why ALL keys should be treated the same.

To me 'rehdat-key' is different from 'linva-key' etc. And I think rawhide can do the same.

The analogy I keep thinking is 'my signature' is differnet than 'RedHat's CEO's signature' treating both to mean the same is nuts..

Satish

On Mon, 1 Nov 2004, Peter Jones wrote:

On Mon, 2004-11-01 at 17:34 -0600, Satish Balay wrote:

...

Ok - you & Seth seem to have a solution to the problem.

Still no good explanation why ALL keys should be treated the same.

Because there's nothing about a key that tells you how to treat it.

Thats because the 'user' decides how to use the key - and had a choice to differenciate.

...

To me 'rehdat-key' is different from 'linva-key' etc. And I think rawhide can do the same.

The analogy I keep thinking is 'my signature' is differnet than 'RedHat's CEO's signature' treating both to mean the same is nuts..

But the signature isn't different in kind. You just "know" which documents one is good on and which one isn't. But we don't have that kind of knowledge for all keys. We don't know which repositories each key is good for what on, and making the infrastructure to tell that about keys is a lot of work. Making the infrastructure for a key to sign something which tells us is significantly easier, I think.

Ok - here you want the key to carry additional pay-load - and the infracture tools automatically use/manage this info.

But I'm thinking the user manages keys - and assigns meaning to it. For eg: I'd like to be able to say:

- if updates signed with 'fedora.us-key' give me a big fat warning. - if update signed with 'fedora.us-key' && foo-bar-key - go ahead and install. (where foo-bar user contributed that package to fedora.us)

I guess both modes should be possible.

Satish

On Thu, Nov 04, 2004 at 11:33:00AM +0100, Nils Philippsen wrote:

Just to overstretch analogies a bit, the "signature" of Fisher-Price on a kid's toy isn't different from the "signature" of Heckler&Koch on a submachine gun either. Despite that they convey very different messages ("when you push the button, the doll cries" vs. "... a whole family cries").

Let's face it, currently a signed package only means "someone/-thing has signed off on it" on a technical level, anything else is just what we

At the technical level but not at the actual human level. At that point brand comes into it.

On Thu, 2004-11-04 at 11:33 +0100, Nils Philippsen wrote:

On Mon, 2004-11-01 at 18:50 -0500, Peter Jones wrote:

...

On Mon, 2004-11-01 at 17:34 -0600, Satish Balay wrote:

...

Ok - you & Seth seem to have a solution to the problem.

Still no good explanation why ALL keys should be treated the same.

Because there's nothing about a key that tells you how to treat it.

Exactly. There's where "common sense" comes into play, i.e. I shouldn't enable Rawhide repositories if a broken system makes me cry.

We're not just talking about rawhide. We're talking about Axil's repo, and Matthais's repo, and the cdparanoia repo on my people.redhat.com site, and the repo on Seth's website.

There is no common sense answer to "I have 40 keys signing things and none of them specify what the signature means".

Quit thinking that we're talking about one key. We're talking about many.

Let's face it, currently a signed package only means "someone/-thing has signed off on it" on a technical level, anything else is just what we humans put into it and nothing tools can guess by themselves. I.e. we can only differentiate between "keys we trust" on a certain system by either putting them into yum.conf/sources or not. Everything beyond that would need infrastructure that currently doesn't exist.

Yes, anything beyond that needs infrastructure that doesn't currently exist. Currently yum and up2date take signatures to mean something beyond that, and they take all signatures in rpm's to equally in this regard. That means we need infrastructure beyond looking at the key and guessing wildly what a signature by it means.

yum and up2date interpret a specific meaning for a package signature: if the key is known to rpm, a valid signature means the package was transmitted as intended from the signer.

It's not even very difficult infrastructure to make (at least in the most naive form), but so far you've objected to nothing except my premise that people don't know what a signature means, which you now seem to agree with. What gives?

On Thu, 2004-11-04 at 17:12 -0500, Peter Jones wrote:

On Thu, 2004-11-04 at 11:33 +0100, Nils Philippsen wrote:

...

On Mon, 2004-11-01 at 18:50 -0500, Peter Jones wrote:

...

On Mon, 2004-11-01 at 17:34 -0600, Satish Balay wrote:

...

Ok - you & Seth seem to have a solution to the problem.

Still no good explanation why ALL keys should be treated the same.

Because there's nothing about a key that tells you how to treat it.

Exactly. There's where "common sense" comes into play, i.e. I shouldn't enable Rawhide repositories if a broken system makes me cry.

We're not just talking about rawhide. We're talking about Axil's repo, and Matthais's repo, and the cdparanoia repo on my people.redhat.com site, and the repo on Seth's website.

There is no common sense answer to "I have 40 keys signing things and none of them specify what the signature means".

Quit thinking that we're talking about one key. We're talking about many.

Yes. Currently the tools (RPM, the RPM format, yum, up2date) don't allow you or me or anyone to codify what a specific key means, i.e. I can only codify "I want only packages from a trusted origin" or nothing at all. Well, I could if all Rawhide packages were signed ;-). Anyway, that's what we have to tell users if they have different ideas about a key -- if it's in your RPM keyring it means RPM and up2date and yum will install a package signed with that key without complaining to you that it's not signed (at all or with an unknown key, doesn't matter).

...

Let's face it, currently a signed package only means "someone/-thing has signed off on it" on a technical level, anything else is just what we humans put into it and nothing tools can guess by themselves. I.e. we can only differentiate between "keys we trust" on a certain system by either putting them into yum.conf/sources or not. Everything beyond that would need infrastructure that currently doesn't exist.

Yes, anything beyond that needs infrastructure that doesn't currently exist. Currently yum and up2date take signatures to mean something beyond that, and they take all signatures in rpm's to equally in this regard. That means we need infrastructure beyond looking at the key and guessing wildly what a signature by it means.

Currently, we can only "emulate" what you want with the available tools, i.e. importing the Rawhide key implicitly lowers the entry level quality of the packages that the tools will install without complaining -- and without the tools knowing that they do it ;-). Seth's extending yum to enable certain keys only for certain repositories helps a bit, but to fully achieve what you describe we really have to extend RPM packages in a way, where a signature can convey meaning beyond "this package passed that signer".

yum and up2date interpret a specific meaning for a package signature: if the key is known to rpm, a valid signature means the package was transmitted as intended from the signer.

It's not even very difficult infrastructure to make (at least in the most naive form), but so far you've objected to nothing except my premise that people don't know what a signature means, which you now seem to agree with. What gives?

Hey, all I said is that we shouldn't take their ill idea on what a signature means as some kind of standard to adhere to. I think it is wrong if we don't sign packages on that basis, it hurts us (and the tester) more if a tester can't verify that he's actually testing the right package (which shouldn't be intentionally malicious) than if someone who doesn't bother to read READMEs, who will probably import any key found on the net into his own RPM keyring ;-), install a Rawhide package on an FC2 system. I fully agree and even proposed extending RPM so that signatures can sign off on multiple things like "origin/build system passed", "QA passed", ... but until this is done we have to live with the limitations of what exists now.

Nils

On Fri, 2004-10-29 at 10:08 -0400, Jeff Spaleta wrote:

On Fri, 29 Oct 2004 15:36:47 +0200, Nils Philippsen nphilipp@redhat.com wrote:

...

This still forces me to use special tools like up2date and yum to access the packages if I want to verify their origins.

actually...no.

you can grab the signed metadata with the md5sums, check the sig on that. and then do a md5sum check comparing the md5sum values in the metadata and the package. You can do the md5sum check by hand. This isn't much different than the situation with the isos. How do you verify you are using the correct isos? you check the md5sums against an md5sum list. How do you check the validity of the md5sum list? You check the md5sum list signature.

OK, not "forces" but "compels" because I don't want to go through this hassle ;-). I can always introduce yet another level of indirection, just to make people use the tools I think they should be using, but is it wise to do so? NB: I am not against signing repo metadata, but I am absolutely in favour of signing every package that "leaves the house" for reasons I stated elsewhere (it is no more burden for the pushing tool to have all packages as well as the metadata signed).

You might argue it would be a good idea if there was a signed flat md5sum list for all packages as well as the xml metadata, so the md5sum command could use it. And then I'll tell you, you need to accept the inevitable future of xml for all possible human communication adopted by unanimous United Nations resolution, and you should fix md5sum to parse xml structure files for md5sum sigs :->

No, we don't want to start another discussion about XML and its benefits and drawbacks. Not even because it's Friday ;-).

And I really really really don't want to encourage people to use rawhide packages randomly from something like an online rpm warehouse. I don't want misinformed people, being able to pick up an individual rawhide package, see that its signed, and use the fact that there is a verifable signature as an easy excuse to assume its totally okay to install. This sort of crap happens a lot with unsigned rawhide, and I don't want people who misunderstand what a signature really means to feel more comfortable installing rawhide packages when they should not be. There is a gap between, the technical definition of what signing a package means, and common perception of what a signed package means. My concerns is not for people like yourself, who understand that a rawhide key doesnt mean anything beyond 'this package was built on the automated rawhide build system." My concern is for the people, the much larger group of people, who will misinterpret the level of trust associated with ANY key and will be that much more inclined to install a random rawhide package they happen to find outside of a rawhide mirror, without thinking about it at all. It doesn't help that as of now rpm key importation can't handle signed keys, and thus web-of-trust metrics can't be used natively to produce a metric of trust of keys. How do you implement verification for those people who understand what it means, without giving a false sense of security and trust for those people who are misinformed about the process who end up using the rawhide packages out of their original context? I say you sign the metadata and have the informed people use the package metadata for verification.

Can rawhide packages be automatically signed... of course Does autosigning help the intended, well informed, audience of the rawhide packages... yes Does autosigning hurt the unintended, un-informed or mis-informed audience... i think it does.

I never denied that there are people who can have a false notion on what a signature on a Rawhide package means. But I absolutely refuse that _I_ should have to jump through hoops due to that, even more so given that the majority of them won't install with RPM but with up2date or yum.

From there it's a short step from "Huh why doesn't this install?" over

asking on some mailing lists or on IRC where someone answers "use gpgcheck=0 or --nosig", i.e. the not-so-well-informed will install Rawhide anyway if you don't expressly forbid it. I'd say that the set of people who insist on signed packages but are clueless about what this means or doesn't mean regarding the quality is rather small ;-).

Nils

On Fri, 2004-10-29 at 08:56 -0400, John Burton wrote:

Nils Philippsen wrote:

[...snip...]

...

I still don't see how signing a package makes it more trustworthy than signing the repo metadata. Signing a package gives me some amount of trust in its origin, not its quality or whatever.

Jumping into this discussion face first... As you said, signing a package gives you some amount of trust in its origin. The trust in its quality is derived from the reputation of the origin, i.e. I would "trust" the quality of a package signed by RedHat before I would "trust" the quality of a package signed by Joe Schmo from xyz. But that "trust" in the RedHat quality would probably be damaged if they were to "sign" pre-release (rawhide) packages. So, releases should be signed, tests should not.

And this assumption is wrong. A signature on a package is absolutely not correlated to the quality of it. To ease the burden on people's brains ;-) we have different keys for RHEL, Fedora, final, beta, Rawhide and whatnot. Therefore there is some kind of weak correlation between the key used to sign the package and the package's quality. People that import the Rawhide key should know that it might hose their systems, if they're not aware of that fact they'd better erase it from their systems (e.g. "rpm -e gpg-pubkey-e418e3aa-3f439953 gpg-pubkey-1cddbca9-3f9da14c" would erase the Rawhide keys from my system).

As far as signing packages vs. signing meta-data... Digital signatures are like real signatures, you want to make sure they are actually attached to what you are signing. If there is a chance that package that the signed meta-data represents can be changed without invalidating the signature, then you've lost the authentication power of the signature. In the non-digital world, you sign each page of a contract, not a seperate blank page attached to the contract. Signing a blank page is meaningless...

ACK.

Nils

On Mon, 1 Nov 2004, Peter Jones wrote:

<snip>

It says that we intended to release it in a form that is fit to be used.

I don't see any problem with this reasoning for rawhide. 'form that is fit to be used' here would imply 'testing'.

(Although clearly it does not imply any warranty, including the implied warranties of merchantability and fitness for a particular purpose ;)

It says we believe that the actual data in the package headers -- the scriptlets, the triggers, the conflicts, the provides, etc. -- are of a quality that Fedora believes is sufficient for release.

rawhide is not a release - so no one will confuse signed packages in rawhide as 'release quality' - and won't eat 'data'. - so no conflict here.

These things are Red Hat's and Fedora's value add, and a signature says that we believe we've actually added value.

Yes - no conflict here. (there is value added in rawhide)

It also conveys that some packager whom we trust has looked over the payload and does not consider its contents to be *hostile* to our users.

This is the primary point of difference. Personally - I'd like to know EXACTLY whats done by the package signer to gaurentee 'no' tampering 'anywhere'. (source/binary/process). My contention is - not much difference other than a 'cursory' check.

Consider RHEL errata. When RH releases an erratum, the signature doesn't just say "this is some package from Red Hat". It says that you can use the signature, combined with the checksums and the data in the erratum. For what can they be used?

No one confuses RHEL errata with Fedora errata - or with rawhide. (none of them are interchangable). So there is no conflict of concepts on signing on this pont (wrt rawhide).

You should already know the answer here. What the signature provides is a way to verify Red Hat's intent and belief that the package in the user's hands does actually fix the problems described in the erratum, and to some (lesser) extent that it does not introduce more problems

No confusion here either - as rawhide packages are never mistaken for erratum packages.

And each branch (RHEL/fedora/rawhide) should have its own differnet gpg-keys anyway.

Satish

On Mon, 1 Nov 2004, Jeff Spaleta wrote:

On Mon, 1 Nov 2004 12:58:22 -0600 (CST), Satish Balay balay@fastmail.fm wrote:

...

No confusion here either - as rawhide packages are never mistaken for erratum packages.

really? noone ever mistakes a package from rawhide as a consumable package? really? no one ever does a random search for a package from an online rpm warehouse and finds a package meant as a piece of rawhide and not as a consumable update? really? no one ever takes packages from the rawhide tree and mixes them with updates and creates a homebrew repository that other users will be using?

i think you need to spend more time in general purpose community forums and watch how often the less informed are confused about what rawhide/development packages are meant for. Everyone in this conversation is in the 1% tail of the distribution of clue in the userbase. Arguing that you are not confused is sort of pointless. I see people confused by what rawhide is, every single day.

Ok the wording of my statement is wrong. (given any tool you'll find somenoe who'll use it incorrectly - and break it (or break something else)

But unless you are saing: somehow the current non-gpg-signed packages are preventing such folks from doing the wrong things (listed above) - and 'gpg-singing' encourages them to do them - your text adds no substance to the discussion.

Satish

On Mon, 1 Nov 2004, Matias Féliciano wrote:

A signature, which can be part of a quality process, ensure where the information/data/package come from. A signature is not a certificate of quality _without_ a quality process.

Totally agree. All the points raised so far were mostly releated to QA for RHEL.

One can argue that even rawhide has a QA - and the gpg-sign is part of the QA proces - However the QA for RHEL is totally different from QA for Fedora (release) - which is different from QA for rawhide. So there is no conflict in the model - and no good reason yet for not gpg-signing.

Any argument which says 'users will confuse gpg-signed rawhide packages as RHEL QA'ed packages' is bogus. (Any user infering this from the gpg-signautre - and thinks its safe to use rawhide instead of fedra-core-release/RHEL is nuts)

Satish

On Thu, 2004-11-04 at 11:08 +0100, Nils Philippsen wrote:

On Mon, 2004-11-01 at 12:27 -0500, Peter Jones wrote:

...

On Fri, 2004-10-29 at 12:57 +0200, Nils Philippsen wrote:

...

If we don't sign packages we make it basically impossible for people to check where a specific package comes from.

Yes, but the current signing method does not do _precisely_ that. It does many things, and that is one affect.

Technically it does only what I said, i.e. the package was signed by someone who basically only signs "this package passed through me", as no additional validation or QA or whatever is involved in the signing step. But see below.

I really don't care about "Technically it does this" arguments; I care about what most of our users understand it to do.

...

...

There is nothing else that a signature on a package says.

That's simply not true.

It says that we intended to release it in a form that is fit to be used. (Although clearly it does not imply any warranty, including the implied warranties of merchantability and fitness for a particular purpose ;)

It says we believe that the actual data in the package headers -- the scriptlets, the triggers, the conflicts, the provides, etc. -- are of a quality that Fedora believes is sufficient for release. These things are Red Hat's and Fedora's value add, and a signature says that we believe we've actually added value.

You're talking about FC final or RHEL final keys/signing, not the Rawhide key.

I'm talking about how most of our users perceive *any* signature, and about how our tools, and tools made by our users, treat signatures of any kind.

If I can't tell the difference in how things should behave by simply looking at the data that's *there*, then there is no difference. What I know because I've learned it on company mailing lists or through talking to people, even if it is part of the corpus of knowledge which we as developers may have, is simply not real for the majority of our users. It is not reality for them, and it is not the reality our current tools are based on.

Signing something with the Red Hat key and signing something with the Rawhide key are currently _the same thing_, and no amount of telling people that it's not is going to change that. There has to actually be data that says it's different, and the tools have to actually look at that data.

...

It also conveys that some packager whom we trust has looked over the payload and does not consider its contents to be *hostile* to our users.

That is the most I would grant a signature with the Rawhide key on a package to convey.

But that doesn't scale past *one* key. This is not 1998, and Red Hat is not the only supplier of packages that run on a Fedora box. The method for telling "this signature means *this thing*" cannot be "look at the signature, and then look the key up in a table in the code".

The right way is a method where we look at the signature, and it has data which includes the key, and the purpose of the signature. It also should be something usable on private networks, so having something like an rss feed to say which key is which also pretty much sucks.

I have to be able to use a key for *exactly* one thing, and that one thing is how much I trust the signature. Everything else needs its data to be part of the data which is being signed.

...

Consider RHEL errata. When RH releases an erratum, the signature doesn't just say "this is some package from Red Hat". It says that you can use the signature, combined with the checksums and the data in the erratum. For what can they be used? You should already know the answer here. What the signature provides is a way to verify Red Hat's intent and belief that the package in the user's hands does actually fix the problems described in the erratum, and to some (lesser) extent that it does not introduce more problems

So, no, it's not just that it comes from Red Hat. That's really a more minor point of what it's for.

OK, we're getting somewhere. We do have several keys with which to sign packages. We do specifically have a Rawhide key which kind of invalidates what you said in an earlier post:

...

No, nobody is "proposing that Rawhide packages shouldn't be signed at all". That's pure spin. They are not currently signed, and I'm arguing against the proposal that they *should* be.

Indeed they are currently signed -- with the exception of a handful of packages. I say that we should close this gap.

Even if you do sign every package, changing update tools to accept that signature still erodes the utility of signing things by a significant amount, unless the signatures can say for themselves what their purpose is. In fact, signing them the way we do erodes it some, but changing the tools is far worse -- it's an acknowledgment that we mean to do this.

Also note that those which are signed are currently signed by hand, and one thing people have been advocating is automatic signing. Automatic signing, I'll obviously argue, is a total loss. But more than that, we don't want to convey.

Your argumentation implies that all package signing keys convey the same message, i.e. "this package was built there and there and fulfils certain quality criteria" which is certainly not true for the Rawhide key.

It's true to our tools, and I think it's true in the eyes of our users. I'm not the only one who's stated this impression, either. Jef put it pretty well the other day talking to Satish:

On Mon, 1 Nov 2004 12:58:22 -0600 (CST), Satish Balay balay@fastmail.fm wrote:

...

No confusion here either - as rawhide packages are never mistaken for erratum packages.

really? noone ever mistakes a package from rawhide as a consumable package? really? no one ever does a random search for a package from an online rpm warehouse and finds a package meant as a piece of rawhide and not as a consumable update? really? no one ever takes packages from the rawhide tree and mixes them with updates and creates a homebrew repository that other users will be using?

There is no part of which key was being used that carries any data about what the signature means, and this is a very significant problem. Why isn't this point clear?

The Rawhide key did not ever tell me more than that this package has been built in the Red Hat build system. This surely is different from what any other RPM signing keys may or may not mean, but it is enough for the purposes for those people who want to test the new stuff but still want to be at least a bit safe that the software they try won't intentionally screw them. Beta/Testing keys might imply a bit more of quality while final keys give me the most in that department. Not every key is the same here ;-).

Again, you're ignoring the difference between intent and perception. We certainly haven't intended for the rawhide keys to say that, but at the same time, all of our tools currently have two classes of keys for signatures: known and unknown. They don't have "known to only mean it's from the right place", which is what you contend the rawhide key is. "If you're on the list, you get into the club," as it were.

And even if they *did* have that concept, there's still no good way to make that scale to more than one source of packages.

A different key does not a different kind of signature make. Really.

On Thu, 2004-11-04 at 15:02 -0600, Satish Balay wrote:

On Thu, 4 Nov 2004, Peter Jones wrote:

...

Signing something with the Red Hat key and signing something with the Rawhide key are currently _the same thing_, and no amount of telling people that it's not is going to change that.

(I didn't want to get sucked into this again - but couldn't resist.. this tread never dies).

I hope you can give pointed answers to these 2 questions.

1. If 'Red Hat key' == 'Rawhide key' - why do you have both?

I think it's horribly ill-conceived that we have both. That is, we have both because people have fallen into this mistake.

2. How does packages signed by 'at-rpms-key' fit in your grad model

where all keys are the same - and users don't know how to distinguish them.

Both models have the keys being the same. One has people refusing to acknowledge this.

The current model is that they're all the same. Look at our tools; look at yum and up2date. They don't know anything about which key is which, just which key you've said you trust (not even what you trust it for, or how much). The only real difference, and certainly the only one in the minds of the vast majority of our users, is that one comes in rpm's key list by default and one does not.

The better question is how one of Axel's package fits into the model Nils insists exists. The only possible answer is that it doesn't fit very well at all. How do I know what Axel means by his signature on his packages? I have no idea, and I don't know where to look to found out, either. I suppose I could email him, but that certainly doesn't scale to a 4th or 5th key very reasonably, much less any more than that.

My model is that the signature is more than just a gpg signature. Conceptually, it's a signature on a certificate with data that specifies exactly which ways the package may be trusted. One could actually implement it that way, which I think we should, but it's some significant effort.

The specific proposal here was that when you *don't* mean the things that people infer from a signed package, don't sign the package. If all we mean is that it's not damaged or tampered with, sign the metadata instead. Seth's metadata proposal (which I believe he's largely implemented) already has the format for this in place. In this case the package is one certificate as mentioned above, and the metadata is another. What the package signature actually means is obviously up for some debate, but we can certainly find plenty of examples where people think it means more than just lack of corruption.

Or should no one other than 'Redhat' be signing packages.

With a model where we recognize the meaning from the key, this is implied, though not necessarily intentionally. With my model, it is not.

On Fri, 5 Nov 2004, seth vidal wrote:

...

The current model is that they're all the same. Look at our tools; look at yum and up2date. They don't know anything about which key is which, just which key you've said you trust (not even what you trust it for, or how much). The only real difference, and certainly the only one in the minds of the vast majority of our users, is that one comes in rpm's key list by default and one does not.

What in rpm's key list by default? I thought the user does an explicit 'rpm --import'

An RFE for yum has been to provide a list of gpg keyids that are valid per-repository.

So then the gpgcheck process would be:

1. check if the sig exists
2. check if the sig is valid
3. if both are true, check to see if the keyid matches on the allowed

keyid for packages from that repo.

A couple of questions here.

- What key is used for this purpose (to sign the metadata)? - Where does the user store this public key? - What prevents the clueless users from having the same expecation from a gpg-signed metada-repo as they have with gpg-signed packages?

thanks, Satish

On Fri, 5 Nov 2004, seth vidal wrote:

This is just based on keys in your rpmdb.

The idea is this:

if you have 3 repos available to yum.

They are signed with 3 separate gpg keys. So you've imported all the keys into your rpmdb. The whole point of the feature I described before is so you can say:

the only packages I want from this repository are signed with _this_ key. If you get a package from this repository that is signed with any other key, even if I have that key in my rpmdb, don't trust it.

Ok - here you are saying EACH package is signed. And this pacakge signature is the one thats compared.

The inferences I get from the above are:

- all packages from all repos should be signed (ideally) - if an unsigned package is part of the dep-resolve list - then yum just aborts the transaction - (Obviously - the main feature) if the 'key' doesn't match the one seecified for this repo in yum.conf - the transaction is aborted.

I do like this new feature. A couple of questions remain.

- Where does sigining 'metadata' fit in here?

- And this scheme would require rawhide pacakges also to be signed with some key. (or am I misreading this?)

thanks, Satish

On Fri, 2004-11-05 at 00:41 -0500, seth vidal wrote:

This, obviously, begins setting up the infrastructure to allow a user to add their own value to specific keys.

Thoughts?

It still lacks any method for a package source to tell a user what the signature means. There's no discovery mechanism.

On Fri, Nov 05, 2004 at 12:34:32AM -0600, Satish Balay wrote:

On Thu, 4 Nov 2004, Peter Jones wrote:

...

My model is that the signature is more than just a gpg signature. Conceptually, it's a signature on a certificate with data that specifies exactly which ways the package may be trusted. One could actually implement it that way, which I think we should, but it's some significant effort.

A signature is a signature, nothing more. You are talking about policies, which are orthogonal to signing. Red Hat has policies, ATrpms has policies, every repo has one, and they may partly overlap. But you cannot (should not) deduce a policy from a signature.

The only thing IMHO a signature should be doing is to ensure the package origin is from the key-holder of the package, nothing more. It is a security, not policy entity.

Yeah - but we don't have that right now. The thing we are debating is

• why signing 'rawhide' with gpg key is wrong.

Signing rawhide packages is not only right, but highly required. I want to know whether mirror XYZ has untampered packages. If the package is signed by the trusted Red Hat keys, I don't need to check or care about mirror trusts. Unsigned packages on an insecure mirror would go unnoticed if modified.

This mail is signed for the very same reason. There is no policy behind signing my mail, other than ensuring noone can tamper with the contents or send (signed) mails on my behalf.

...

The specific proposal here was that when you *don't* mean the things that people infer from a signed package, don't sign the package.

You mean Axel, Dag should't sign the packages they distribute. (because that would imply its equally trustworthy as redhat-certified)

And according to your model - If I were to distribure signed/unsigned packages - the expection for unsigned is different(can eat data) - but signed is different (extremely stable)

I'd say unsigned packages are just insecure, so they are also unstable. OK ;)

On Fri, Nov 05, 2004 at 10:58:37AM +0100, Arjan van de Ven wrote:

On Fri, 2004-11-05 at 10:50 +0100, Axel Thimm wrote:

...

On Fri, Nov 05, 2004 at 12:34:32AM -0600, Satish Balay wrote:

...

On Thu, 4 Nov 2004, Peter Jones wrote:

...

My model is that the signature is more than just a gpg signature. Conceptually, it's a signature on a certificate with data that specifies exactly which ways the package may be trusted. One could actually implement it that way, which I think we should, but it's some significant effort.

A signature is a signature, nothing more. You are talking about policies, which are orthogonal to signing. Red Hat has policies, ATrpms has policies, every repo has one, and they may partly overlap. But you cannot (should not) deduce a policy from a signature.

The only thing IMHO a signature should be doing is to ensure the package origin is from the key-holder of the package, nothing more. It is a security, not policy entity.

Well policy and security somewhat interact. The value you give the the signature depends on the policy. Most extreme example: if I put my secret key on a public webpage, there is no value in signing anything with it at all.

Of course nobody sane is going to do that, so it's clear that there is some value in signing. And I can even see even the point of having multiple signatures:

• The buildsystem that builds the rpm signs for having build the package
• The person doing QA signs the package for having passed the required

checks

• The release manager (eg RH or you or Dag) signs for publishing the

package (whether it is automated or not that's besides the point)

• The mirror signs the package as a "pass through"

that way you even create an authentication trail.... And you can decide which to trust for what.

I thought rpm signing allowed only one signature, otherwise strange things happen, or not? Don't remember whether that was an rpm bug that could be fixed w/o breaking backwards compatibility, but I remember it had some implication which is why it wasn't fixed and instead signing keys had to be adjusted.

Otherwise I agree with the general workflow, but probably mirrors should not be signing at all - each package would appear different on each mirror (and a courier doesn't sign a document either ;) -, and the end user does not care who did internal QA (the release managers do though).

The end user should see simple one-key signing to keep his logistics low. Perhaps the above model should be done by signature replacement (QA replaces build-system signature with its own, release manager replaces QA signature).

Anyway the thread's recommendation to disallow signing because signing would imply certain policies would be very wrong.

Le jeudi 04 novembre 2004 à 15:37 -0500, Peter Jones a écrit :

Also note that those which are signed are currently signed by hand, and one thing people have been advocating is automatic signing. Automatic signing, I'll obviously argue, is a total loss.

What is a ssl server if it's not an automatic signing machine ? Total loss...

Le vendredi 05 novembre 2004 à 11:10 -0500, Peter Jones a écrit :

On Thu, 2004-11-04 at 23:45 +0100, Féliciano Matias wrote:

...

Le jeudi 04 novembre 2004 à 15:37 -0500, Peter Jones a écrit :

...

Also note that those which are signed are currently signed by hand, and one thing people have been advocating is automatic signing. Automatic signing, I'll obviously argue, is a total loss.

What is a ssl server if it's not an automatic signing machine ? Total loss...

That's completely ignoring the contexts of package distribution and the policies put in place by current package update tools. None of them trust packages *just* because they are fetched over SSL,

Again, you (and many others) are mixing things.

a) I do not trust rawhide package (for mission critical system). I trust RHEL packages (for mission critical system).

b) I can't trust the origin of unsigned rawhide package. I can't trust the origin of unsigned RHEL package.

c) I trust the origin of signed rawhide package. I trust the origin of signed RHEL package.

a) is not related to signed or unsigned packages. Should I trust/install RHEL packages _only_ because they are signed ? NO !

Signed RHEL packages guaranties the package origin. Nothing more. Support and reputation of Red Hat give me the "feeling" that I should trust RHEL package (My knowledge tell me this is true only for a RHEL installation and with a good administrator :-)).

Should I trust this package only because it is signed ? : $rpm -K -v hdparm-5.7-2.2.i586.rpm hdparm-5.7-2.2.i586.rpm: Hachage de l'entête SHA1: OK (91f6e5752df69fb07a8f28badd3c90e91eaa0c37) Somme MD5: OK (eb24fab7ac89e67fb2e882fd11e7ee07) signature V3 DSA: NOKEY, key ID 9c800aca

Is this package suitable for mission critical ? : $ rpm -K -v hdparm-5.7-2.i386.rpm hdparm-5.7-2.i386.rpm: Entête signature V3 DSA: OK, key ID 4f2a6fd2 Hachage de l'entête SHA1: OK (0115990d6b8e85627bdf24a1f7f8f74627ea5a2b) Somme MD5: OK (9621b9025c6538da72605fade8d028ed) signature V3 DSA: OK, key ID 4f2a6fd2

You can *not* answer these two questions only with the signature. Period.

Signed package, mean ONE thing and only ONE thing. We should not base own through on wrong definition.

It's time to Red Hat to define what Rawhide is/mean. Signed (or not) package is out of the scope of this definition.

nor do they reject packages which aren't. -- Peter

nodata said:

...

How? Would it make you feel better if the fake updates had installed a signature first? Or told you that you had to install a new key from the fake site? The ONLY thing that signatures tell you is that the RPM has been signed with a particular key, that's it.

An rpm signed by Red Hat tells me that Red Hat signed it. No signature == no install.

Have you read the fake e-mail? RPM was never mentioned. And again, if you are falling for an e-mail that has you run an arbitrary script, any key can be installed to look like a Red Hat key.

Many of the releases in Rawhide are not signed, why not?

This has been discussed over and over, so look at the archives. Basically it boils down to the Rawhide RPMs being automatically generated when there isn't always someone around to sign them. Since the whole point of Rawhide is to get new bits out the door the choice is made not to hold them for a live body to sign them.

On Tue, 2004-10-26 at 15:13 +0200, nodata wrote:

...

This has been discussed over and over, so look at the archives. Basically it boils down to the Rawhide RPMs being automatically generated when there isn't always someone around to sign them. Since the whole point of Rawhide is to get new bits out the door the choice is made not to hold them for a live body to sign them.

Then perhaps rawhide should be signed with a separate key that signs the packages without a live body.

If this is done then it severely reduces the relevance of having them signed in the first place.

My understanding is that, when a package is "signed" by redhat, a human steps up to the plate, does certain verifications, then puts in the pass phrase, and hey presto you have a signed package.

Your suggestion automates the whole process, and drastically reduces the security model.

Personally, I am 100% happy for the sandpit to continue to be unsigned, so long as test/released packages are signed, I am happy.

To me, rawhide is only half a step away from CVS, should the CVS access (once made public) also have every thing GPG signed?

Doug

nodata wrote:

MD5sums are probably already available for Rawhide, but yum doesn't (AFAIK) verify these against MD5sums published by Red Hat on Red Hat's site.

An md5sum is integrated in the rpm itsselves... $ rpm -K udev-039-1.i386.rpm udev-039-1.i386.rpm: sha1 md5 OK

nodata said: [snip]

Aside from the verifications carried out by the human (I'm not sure what these are), the signed package from Red Hat would have one important advantage over an unsigned package from Red Hat - that it really did pass through one of the Red Hat build servers.

As the Fedora process opens up this distinction becomes less and less important. Who's to say the malicious person isn't a previously trusted contributor who has decided to work on a different project? Or, as others have pointed out, the build server itself has been cracked?

-- William Hooper

On Oct 26, 2004, "nodata" fedora@nodata.co.uk wrote:

Aside from the verifications carried out by the human (I'm not sure what these are), the signed package from Red Hat would have one important advantage over an unsigned package from Red Hat - that it really did pass through one of the Red Hat build servers.

No. It would only prove that the package passed through a box that had the signing key. The more machines have access to such key, and the more entry points such machines have, the more likely it is that someone could abuse the keys to signing packages that didn't go through the build servers, and the more likely it becomes that the key leaks and starts being used for malicious purposes. Sure enough, in a perfect world, this shouldn't happen, but the world we live in is far from that, so it's only reasonable to take care to avoid leaks, and to avoid getting packages signed that didn't go through the build system.

I think the core issue here is that yum users tracking Rawhide should have a way to verify that a package has come through Red Hat.

Just don't let yum install packages that aren't signed. How about you start a rawhide mirror with the following properties: if a package is not signed, it won't be in your mirror; you'll keep the previous version of such package instead.

An alternative is to script a yum wrapper that, when encountering an unsigned package, automatically excludes that and retries, until you get only signed packages installed. Heck, wouldn't it be way so cool if yum could do it all by itself?

It's unlikely that signed packages will have dependencies on unsigned packages, because of the way signing is done, so odds are that, given daily rawhide pushes, you'd be able to move forward quite regularly.

If yum could provide a lesser degree of verification, by verifying checksums instead of signatures, this wouldn't be a bad thing?

Err... Doesn't it? up2date does, and so does rpm.

...

To me, rawhide is only half a step away from CVS, should the CVS access (once made public) also have every thing GPG signed?

Perhaps :)

monotone!

On Oct 26, 2004, seth vidal skvidal@phy.duke.edu wrote:

...

Just don't let yum install packages that aren't signed. How about you start a rawhide mirror with the following properties: if a package is not signed, it won't be in your mirror; you'll keep the previous version of such package instead.

Then it would not be a rawhide mirror. It would be a rawhide distortion.

mirror implies an identical reflection. :)

Well, not quite. Plane mirrors do. And, even then, there's a small delay for the light to get from you to the mirror and back, so when you see your image in the mirror, you're no longer what you're seeing there :-) This wouldn't be that different :-)

You could download the header from the package and look beyond it to see if there are any non-md5/sha1 signatures and if any of those are gpg signatures. However, you won't be able to know if it passes the sig check w/o downloading the whole package. And boy would that suck for the user.

No dispute here. But if it could, later on, realize that the package was signed and use http interval fetch tricks to obtain only the signature, it would be way cool.

...

It's unlikely that signed packages will have dependencies on unsigned packages, because of the way signing is done, so odds are that, given daily rawhide pushes, you'd be able to move forward quite regularly.

except that testing would crawl to a halt on the unsigned packages.

Which would be a good reason for the key bearers :-) to actually sign packages that go to rawhide more often.

On Tue, 26 Oct 2004, Douglas Furlong wrote:

On Tue, 2004-10-26 at 15:13 +0200, nodata wrote:

...

Then perhaps rawhide should be signed with a separate key that signs the packages without a live body.

+1

If this is done then it severely reduces the relevance of having them signed in the first place.

no it doesn't (see note below)

My understanding is that, when a package is "signed" by redhat, a human steps up to the plate, does certain verifications, then puts in the pass phrase, and hey presto you have a signed package.

Your suggestion automates the whole process, and drastically reduces the security model.

It will be much better than the current model of no signatures.

And 'rawhide-gpg-key' could mean 'rpm built on redhat-beehieve' - and nothing more. It shouldn't have to mean beehieve not hacked & 'rawhide-gpg-key' is not stolen.

Also, I'm not sure how the human intervention guarantees that the key/passphrases arn't stolen. The only way I can think of is hardware-encryption (aka palladium?) where keys can never be copied/stolen (in which case passphrases are not necessary)

And as a user - I should be able to query rpm db with:

list all packages currently installed that are signed with the key 'rawhide-gpg-key'

Satish