[pacman-dev] pacman signing security vulnerabilities

newer
[pacman-dev] [PATCH] Use CALLOC...

Michael Seiwald

8 Feb 2011 8 Feb '11

8:47 p.m.

Hello there! We are two students from Austria and have evaluated the ‘gpg’ branch of pacman by Allan, among other package managers, in the course of a project on secure package management. We have found a few points that could be seen as security problems so we thought we’d let you know about them. (1) Unlimited size of signature/sync db If pacman is confronted with signature or sync db files with unlimited size, it just keeps downloading them until the partition containing /var/lib/pacman is filled up. This could be exploited in Denial-of-Service-Attacks, e.g. preventing the writing of log data or mails. Solution: Limit the maximum size of the sync db and signature files to a specified value (e.g. 20MB) when downloading them. (2) Packages with unlimited size This scenario is similar to the above, but this time the size of the packages is known from the sync db. Solution: only download packages up to the size specified in the sync db; abort the download afterwards. (3) Repository Freeze Attacks An attacker is able to prevent clients from updating by replaying an old sync db file with a valid signature. This could be used to keep clients from updating software with known vulnerabilities. Solution: gpg-signatures already contain a timestamp. Before each update, pacman could check if the timestamp is not older than a specified period (e.g. a week). (4) Signing keys Currently when adding a signed package to the repository with repo-add, the signature of the package itself (generated with the package maintainers’ key) is included into the sync db (as %PGPSIG% field in the desc file of the package). Afterwards, the updated sync db is also signed. Firstly, we are not sure how this should be handled in practice. Will the sync db be signed with a central repository key? Or with one of the developers’ keys? Either way, the package signature in the sync db (%PGPSIG%) adds no additional security value, because when pacman verifies both the package signature and the signature of the sync db, it uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the signatures. If an attacker can acquire a private key of any maintainer he can generate valid signatures for every package and also for the sync db. The more maintainers there are, the more private keys are around and the bigger is the risk of a key being compromised. Suggestions: there are different ways to improve the situation. One possibility would be to remove the package signatures from the the sync db and only sign the sync db itself with a central repository key on the server. This is the way Debian does it. Of course this requires some kind of system where the maintainers can submit their (signed) packages. The server would then verify the signature and afterwards automatically sign the updated sync db with the repository key. Another possibility would be to keep the maintainers’ signature in the package (e.g. in the .PKGINFO file) and differentiate between maintainer keys and the repository key when verifying the signatures in pacman (i.e. separate keyrings in /etc/pacman.d/gnupg). Then the package signatures would add additional security because an attacker in possession of the central repository key could not sign the packages themselves. An attacker in possession of any maintainer key could not sign the root metadata (sync db), either. We are happy to see that Archlinux finally gets package signatures and hope that with our suggestions we can contribute to improving the security of the architecture before the new system is actually rolled out. Best regards, Christoph Michael

Show replies by date

Dan McGee

8 Feb 8 Feb

10:02 p.m.

On Tue, Feb 8, 2011 at 2:47 PM, Michael Seiwald wrote:

...

Hello there!

We are two students from Austria and have evaluated the ‘gpg’ branch of pacman by Allan, among other package managers, in the course of a project on secure package management. We have found a few points that could be seen as security problems so we thought we’d let you know about them.

Awesome! Thanks for looking at this stuff. I know our primary efforts haven't been focused on this in a while but it has to be tackled as our next big project.

...

(1) Unlimited size of signature/sync db If pacman is confronted with signature or sync db files with unlimited size, it just keeps downloading them until the partition containing /var/lib/pacman is filled up. This could be exploited in Denial-of-Service-Attacks, e.g. preventing the writing of log data or mails. Solution: Limit the maximum size of the sync db and signature files to a specified value (e.g. 20MB) when downloading them.

(2) Packages with unlimited size This scenario is similar to the above, but this time the size of the packages is known from the sync db. Solution: only download packages up to the size specified in the sync db; abort the download afterwards.

Both interesting. The second one makes quite a bit of sense (Dave, you listening?). The first is interesting. Yes, an avenue for DOS, but so is pinging your webserver with tons of requests or any of a multitude of other things that would cause continuous writes. 20 MB seems potentially low for example, if you are using sync databases containing files entries or something (community has a ~4.5 MB database, conceivably someone could have one larger without being malicious). Most of all I just don't want a hardcoded limit that would ever be restrictive, so I don't know what the answer is here. tl;dr We have a potential problem but I'm not sure of its true severity.

...

(3) Repository Freeze Attacks An attacker is able to prevent clients from updating by replaying an old sync db file with a valid signature. This could be used to keep clients from updating software with known vulnerabilities. Solution: gpg-signatures already contain a timestamp. Before each update, pacman could check if the timestamp is not older than a specified period (e.g. a week).

Yes, very well known, and the site I tell all people to have a read before hacking on this stuff: http://www.cs.arizona.edu/stork/packagemanagersecurity/ We will find a way to address this before we consider package signing complete.

...

(4) Signing keys Currently when adding a signed package to the repository with repo-add, the signature of the package itself (generated with the package maintainers’ key) is included into the sync db (as %PGPSIG% field in the desc file of the package). Afterwards, the updated sync db is also signed. Firstly, we are not sure how this should be handled in practice. Will the sync db be signed with a central repository key? Or with one of the developers’ keys? Either way, the package signature in the sync db (%PGPSIG%) adds no additional security value, because when pacman verifies both the package signature and the signature of the sync db, it uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the signatures. But not one key, and how does one verify a package they got that was not in a sync DB? Or in a sync DB managed by someone they may trust less, but packaged by someone they may trust more?

...

If an attacker can acquire a private key of any maintainer he can generate valid signatures for every package and also for the sync db. The more maintainers there are, the more private keys are around and the bigger is the risk of a key being compromised. Sure- but I'm not quite sure why this makes a difference- if just the DB is signed, or the DB + packages, the same keys would be viewed as valid for both.

...

Suggestions: there are different ways to improve the situation. One possibility would be to remove the package signatures from the the sync db and only sign the sync db itself with a central repository key on the server. This is the way Debian does it. Of course this requires some kind of system where the maintainers can submit their (signed) packages. So now you've opened up another can of worms, from what I see. If the database key was compromised, every package also has to be viewed as compromised or possibly tampered with. If 100 packages are signed with ~15 different keys, even if whatever key last signed the repository is compromised, we don't have to reverify any existing packages except those signed with the compromised key.

...

The server would then verify the signature and afterwards automatically sign the updated sync db with the repository key. Another possibility would be to keep the maintainers’ signature in the package (e.g. in the .PKGINFO file) It is impossible to sign yourself, so this is not going to work, unless I'm missing something. Even with that said, how is a detached signature any less secure, whether it be in a standalone file or

So yes, there is the possibility of someone trying to resign every package, but that could be seemingly prevented or at least guarded against with smart backups and snapshots. No matter what, private keys should not be ending up on a central server (outside of maybe a repo-signing key)- that is too dangerous as you point out. base64 encoded in the sync repository?

...

and differentiate between maintainer keys and the repository key when verifying the signatures in pacman (i.e. separate keyrings in /etc/pacman.d/gnupg). Then the package signatures would add additional security because an attacker in possession of the central repository key could not sign the packages themselves. An attacker in possession of any maintainer key could not sign the root metadata (sync db), either. This makes a lot of sense- keeping the two sets of keys as independent verification would help, although in the case of any private repo, I would expect the same signature on both package and DB, so we would still want a way to allow for that.

...

We are happy to see that Archlinux finally gets package signatures and hope that with our suggestions we can contribute to improving the security of the architecture before the new system is actually rolled out.

Best regards,

Christoph Michael

Thanks guys!

Denis A. Altoé Falqueto

11:43 p.m.

On Tue, Feb 8, 2011 at 8:02 PM, Dan McGee wrote:

...

On Tue, Feb 8, 2011 at 2:47 PM, Michael Seiwald wrote:

...
Hello there!

We are two students from Austria and have evaluated the ‘gpg’ branch of pacman by Allan, among other package managers, in the course of a project on secure package management. We have found a few points that could be seen as security problems so we thought we’d let you know about them.

Awesome! Thanks for looking at this stuff. I know our primary efforts haven't been focused on this in a while but it has to be tackled as our next big project.

I second those words. New blood is always good to renew the motivation :) I would like to know if you have also read the wiki page about the policy of handling the signature process. The link is https://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman. If you didn't know about it, please feel free to suggest any modifications.

...

...
(1) Unlimited size of signature/sync db If pacman is confronted with signature or sync db files with unlimited size, it just keeps downloading them until the partition containing /var/lib/pacman is filled up. This could be exploited in Denial-of-Service-Attacks, e.g. preventing the writing of log data or mails. Solution: Limit the maximum size of the sync db and signature files to a specified value (e.g. 20MB) when downloading them.

(2) Packages with unlimited size This scenario is similar to the above, but this time the size of the packages is known from the sync db. Solution: only download packages up to the size specified in the sync db; abort the download afterwards.

Both interesting. The second one makes quite a bit of sense (Dave, you listening?). The first is interesting. Yes, an avenue for DOS, but so is pinging your webserver with tons of requests or any of a multitude of other things that would cause continuous writes. 20 MB seems potentially low for example, if you are using sync databases containing files entries or something (community has a ~4.5 MB database, conceivably someone could have one larger without being malicious). Most of all I just don't want a hardcoded limit that would ever be restrictive, so I don't know what the answer is here.

tl;dr We have a potential problem but I'm not sure of its true severity.

Maybe we could choose a limit just to avoid the fact of having none. For example, 200 MB for database and 2 MB for signatures. That should be enough for the foreseeable future. If needed, a change would be very straightforward.

...

...
(3) Repository Freeze Attacks An attacker is able to prevent clients from updating by replaying an old sync db file with a valid signature. This could be used to keep clients from updating software with known vulnerabilities. Solution: gpg-signatures already contain a timestamp. Before each update, pacman could check if the timestamp is not older than a specified period (e.g. a week).

Yes, very well known, and the site I tell all people to have a read before hacking on this stuff: http://www.cs.arizona.edu/stork/packagemanagersecurity/

We will find a way to address this before we consider package signing complete.

I remember some talking about that in the mailing list. It was suggested to have a time limit for the validity of the database signature, so the developers would have to generate a new signature at least every n days, if the database didn't change. That would be a worst case scenario, because the rolling release nature of Arch generates lots of database updates and they would be signed very often.

...

...
(4) Signing keys Currently when adding a signed package to the repository with repo-add, the signature of the package itself (generated with the package maintainers’ key) is included into the sync db (as %PGPSIG% field in the desc file of the package). Afterwards, the updated sync db is also signed. Firstly, we are not sure how this should be handled in practice. Will the sync db be signed with a central repository key? Or with one of the developers’ keys? Either way, the package signature in the sync db (%PGPSIG%) adds no additional security value, because when pacman verifies both the package signature and the signature of the sync db, it uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the signatures. If an attacker can acquire a private key of any maintainer he can generate valid signatures for every package and also for the sync db. The more maintainers there are, the more private keys are around and the bigger is the risk of a key being compromised. Suggestions: there are different ways to improve the situation. One possibility would be to remove the package signatures from the the sync db and only sign the sync db itself with a central repository key on the server. This is the way Debian does it. Of course this requires some kind of system where the maintainers can submit their (signed) packages. So now you've opened up another can of worms, from what I see. If the database key was compromised, every package also has to be viewed as compromised or possibly tampered with. If 100 packages are signed with ~15 different keys, even if whatever key last signed the repository is compromised, we don't have to reverify any existing packages except those signed with the compromised key.

So yes, there is the possibility of someone trying to resign every package, but that could be seemingly prevented or at least guarded against with smart backups and snapshots.

No matter what, private keys should not be ending up on a central server (outside of maybe a repo-signing key)- that is too dangerous as you point out.

Yes, that is really a problem. I agree that we should avoid putting private keys on any server. We should base the solution on the concept of web of trust, so that would not depend on any implementation in Pacman. I mean, Pacman just trust the response given by gpg, that will, in its turn, be based on the trust level and relationship of keys defined by the final user (remember, we assume the users know what they are doing and are the only ones responsible for their system). I'm trying to devise an algorithm that could have the following properties: * must be run in the machine of the developer, so the private key doesn't need to be kept in other places; * must sign the packages that are stored in the server, to avoid unnecessary file transfers * be not very different of repo-add, so the developers doesn't feel demotivated to acquire a new habit If someone have some suggestions, please feel free to talk.

...

...
The server would then verify the signature and afterwards automatically sign the updated sync db with the repository key. Another possibility would be to keep the maintainers’ signature in the package (e.g. in the .PKGINFO file) It is impossible to sign yourself, so this is not going to work, unless I'm missing something. Even with that said, how is a detached signature any less secure, whether it be in a standalone file or base64 encoded in the sync repository?

Yes, it is not possible because a package is only a compacted .tar file for the final content of the package. Debian and RPM, for the other way, already have internal sub-archives that separate the real content from the signatures. We don't have that and, as far as I know, are not going to change the format of the packages.

...

...
and differentiate between maintainer keys and the repository key when verifying the signatures in pacman (i.e. separate keyrings in /etc/pacman.d/gnupg). Then the package signatures would add additional security because an attacker in possession of the central repository key could not sign the packages themselves. An attacker in possession of any maintainer key could not sign the root metadata (sync db), either. This makes a lot of sense- keeping the two sets of keys as independent verification would help, although in the case of any private repo, I would expect the same signature on both package and DB, so we would still want a way to allow for that.

Yes, but we would have to make a little more effort for the people that own the keys for database signing. That should be kept in mind when devising the solution. And the implementation should be kept external to pacman itself (it should rely solely on gpg and the web of trust, if possible).

...

...
We are happy to see that Archlinux finally gets package signatures and hope that with our suggestions we can contribute to improving the security of the architecture before the new system is actually rolled out.

Best regards,

Again, thanks for taking the time to discuss that with us. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------

Dan McGee

9 Feb 9 Feb

12:02 a.m.

On Tue, Feb 8, 2011 at 5:43 PM, Denis A. Altoé Falqueto wrote:

...

On Tue, Feb 8, 2011 at 8:02 PM, Dan McGee wrote:

...
On Tue, Feb 8, 2011 at 2:47 PM, Michael Seiwald wrote:

...
(3) Repository Freeze Attacks An attacker is able to prevent clients from updating by replaying an old sync db file with a valid signature. This could be used to keep clients from updating software with known vulnerabilities. Solution: gpg-signatures already contain a timestamp. Before each update, pacman could check if the timestamp is not older than a specified period (e.g. a week).

Yes, very well known, and the site I tell all people to have a read before hacking on this stuff: http://www.cs.arizona.edu/stork/packagemanagersecurity/

We will find a way to address this before we consider package signing complete.

I remember some talking about that in the mailing list. It was suggested to have a time limit for the validity of the database signature, so the developers would have to generate a new signature at least every n days, if the database didn't change. That would be a worst case scenario, because the rolling release nature of Arch generates lots of database updates and they would be signed very often.

Allan and I are going to repeat this until our heads explode, but pacman != Arch Linux. What was that? pacman != Arch Linux. This needs to somehow be feasible for *everyone*, or at least not get in their way. I've had (although it has gone stagnant) my one-package eee kernel repo; I shouldn't have to sign that every 10 days if nothing changes, nor should some in-office repo providing a custom 10 packages or so, esp. if said database can be fetched from a reliable (HTTPS with valid cert, say) source.

...

...
...
(4) Signing keys Currently when adding a signed package to the repository with repo-add, the signature of the package itself (generated with the package maintainers’ key) is included into the sync db (as %PGPSIG% field in the desc file of the package). Afterwards, the updated sync db is also signed. Firstly, we are not sure how this should be handled in practice. Will the sync db be signed with a central repository key? Or with one of the developers’ keys? Either way, the package signature in the sync db (%PGPSIG%) adds no additional security value, because when pacman verifies both the package signature and the signature of the sync db, it uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the signatures. If an attacker can acquire a private key of any maintainer he can generate valid signatures for every package and also for the sync db. The more maintainers there are, the more private keys are around and the bigger is the risk of a key being compromised. Suggestions: there are different ways to improve the situation. One possibility would be to remove the package signatures from the the sync db and only sign the sync db itself with a central repository key on the server. This is the way Debian does it. Of course this requires some kind of system where the maintainers can submit their (signed) packages. So now you've opened up another can of worms, from what I see. If the database key was compromised, every package also has to be viewed as compromised or possibly tampered with. If 100 packages are signed with ~15 different keys, even if whatever key last signed the repository is compromised, we don't have to reverify any existing packages except those signed with the compromised key.

So yes, there is the possibility of someone trying to resign every package, but that could be seemingly prevented or at least guarded against with smart backups and snapshots.

No matter what, private keys should not be ending up on a central server (outside of maybe a repo-signing key)- that is too dangerous as you point out.

Yes, that is really a problem. I agree that we should avoid putting private keys on any server. We should base the solution on the concept of web of trust, so that would not depend on any implementation in Pacman. I mean, Pacman just trust the response given by gpg, that will, in its turn, be based on the trust level and relationship of keys defined by the final user (remember, we assume the users know what they are doing and are the only ones responsible for their system).

I'm trying to devise an algorithm that could have the following properties:

* must be run in the machine of the developer, so the private key doesn't need to be kept in other places; * must sign the packages that are stored in the server, to avoid unnecessary file transfers At least in the "standard" development and packaging scenario, these first two things are happening on the developer's machine. I don't see too many cases where a developer should use a specific signing key on more than one machine; that way if some build machine key gets compromised it can be revoked without having to revoke all keys. If I am remembering GPG right.

...

* be not very different of repo-add, so the developers doesn't feel demotivated to acquire a new habit Either people use it or don't, but enforcement comes via policy on this one- obviously our main repos will always have it, but I agree making it easy enough for everyone to want to use it is also a good thing.

...

If someone have some suggestions, please feel free to talk.

Denis A. Altoé Falqueto

12:42 a.m.

On Tue, Feb 8, 2011 at 10:02 PM, Dan McGee wrote:

...

On Tue, Feb 8, 2011 at 5:43 PM, Denis A. Altoé Falqueto wrote:

...
On Tue, Feb 8, 2011 at 8:02 PM, Dan McGee wrote:

...
On Tue, Feb 8, 2011 at 2:47 PM, Michael Seiwald wrote:

...
(3) Repository Freeze Attacks An attacker is able to prevent clients from updating by replaying an old sync db file with a valid signature. This could be used to keep clients from updating software with known vulnerabilities. Solution: gpg-signatures already contain a timestamp. Before each update, pacman could check if the timestamp is not older than a specified period (e.g. a week).

Yes, very well known, and the site I tell all people to have a read before hacking on this stuff: http://www.cs.arizona.edu/stork/packagemanagersecurity/

We will find a way to address this before we consider package signing complete.

I remember some talking about that in the mailing list. It was suggested to have a time limit for the validity of the database signature, so the developers would have to generate a new signature at least every n days, if the database didn't change. That would be a worst case scenario, because the rolling release nature of Arch generates lots of database updates and they would be signed very often.

Allan and I are going to repeat this until our heads explode, but pacman != Arch Linux.

What was that?

pacman != Arch Linux.

Yes, of course, my fault :) I always forget about it. Probably you'll have to remember me some more times :)

...

This needs to somehow be feasible for *everyone*, or at least not get in their way. I've had (although it has gone stagnant) my one-package eee kernel repo; I shouldn't have to sign that every 10 days if nothing changes, nor should some in-office repo providing a custom 10 packages or so, esp. if said database can be fetched from a reliable (HTTPS with valid cert, say) source.

Maybe each database could have a property specifying the length of validity? It could be in days and 0 could be always valid. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------

Michael Seiwald

15 Feb 15 Feb

1:18 p.m.

Hello, sorry for the late answer. so since we think that some of our points got misunderstood, we would like to clarify some aspects. On 02/08/2011 11:02 PM, Dan McGee wrote:

...

...
(4) Signing keys Currently when adding a signed package to the repository with repo-add, the signature of the package itself (generated with the package maintainers’ key) is included into the sync db (as %PGPSIG% field in the desc file of the package). Afterwards, the updated sync db is also signed. Firstly, we are not sure how this should be handled in practice. Will the sync db be signed with a central repository key? Or with one of the developers’ keys? Either way, the package signature in the sync db (%PGPSIG%) adds no additional security value, because when pacman verifies both the package signature and the signature of the sync db, it uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the signatures. But not one key, and how does one verify a package they got that was not in a sync DB? Or in a sync DB managed by someone they may trust less, but packaged by someone they may trust more?

A package not in a sync DB cannot be verified - regardless of keeping the package signature in the sync db. If the sync DB is signed, the hash of the package file is sufficient to verify its integrity. The only way allowing for the verification of packages which are not part of the sync DB I can think of would be to somehow make the packages contain the signatures (like RPM packages).

...

...
If an attacker can acquire a private key of any maintainer he can generate valid signatures for every package and also for the sync db. The more maintainers there are, the more private keys are around and the bigger is the risk of a key being compromised. Sure- but I'm not quite sure why this makes a difference- if just the DB is signed, or the DB + packages, the same keys would be viewed as valid for both.

If only the DB is signed, the private key could lie encrypted on a guarded server. So instead of having multiple scattered private keys, one would suffice.

...

...
Suggestions: there are different ways to improve the situation. One possibility would be to remove the package signatures from the the sync db and only sign the sync db itself with a central repository key on the server. This is the way Debian does it. Of course this requires some kind of system where the maintainers can submit their (signed) packages. So now you've opened up another can of worms, from what I see. If the database key was compromised, every package also has to be viewed as compromised or possibly tampered with. If 100 packages are signed with ~15 different keys, even if whatever key last signed the repository is compromised, we don't have to reverify any existing packages except those signed with the compromised key.

Our point was: If an attacker gets hold of any maintainer key, he can modify arbitrary packages and re-sign them and also the sync db. This does not necessarily has to be on the main archlinux server but could also be achieved through Man-In-The-Middle attacks on a syncing mirror. The mirror could even be hosted by a malicious entity.

...

So yes, there is the possibility of someone trying to resign every package, but that could be seemingly prevented or at least guarded against with smart backups and snapshots.

But only on the main archlinux server. You could not prevent an attacker from hosting malicious mirrors with correct signatures. GPG key revocation solves this issue but is not that easy - revocations have to be downloaded and checked against before every update operation (during which the keys could be modified or substituted, a backdoor installed etc.).

...

No matter what, private keys should not be ending up on a central server (outside of maybe a repo-signing key)- that is too dangerous as you point out.

In our opinion having one key on a central, guarded server is better than having multiple keys scattered on various client machines. The key could still be protected by a passphrase and only unlocked (manually) during the signature process.

...

...
The server would then verify the signature and afterwards automatically sign the updated sync db with the repository key. Another possibility would be to keep the maintainers’ signature in the package (e.g. in the .PKGINFO file) It is impossible to sign yourself, so this is not going to work, unless I'm missing something. Even with that said, how is a detached signature any less secure, whether it be in a standalone file or base64 encoded in the sync repository?

Yes, we didn’t think about Arch’s package format when writing this. But verifying packages which are not in the sync DB would only be possible with either a detached package signature (then the user would have to download two files) or a signature that is somehow inside the package (which would require a change in Arch’s package format). The main problem is that including the package signatures in the sync db without pacman differentiating between repo- and maintainer keys makes the whole thing less secure because there are more keys around which could get compromised. What would make the whole process a lot more secure is choosing specifically the public key of the maintainer of the package (which can be obtained from the sync DB) when verifying packages.

...

...
and differentiate between maintainer keys and the repository key when verifying the signatures in pacman (i.e. separate keyrings in /etc/pacman.d/gnupg). Then the package signatures would add additional security because an attacker in possession of the central repository key could not sign the packages themselves. An attacker in possession of any maintainer key could not sign the root metadata (sync db), either. This makes a lot of sense- keeping the two sets of keys as independent verification would help, although in the case of any private repo, I would expect the same signature on both package and DB, so we would still want a way to allow for that.

Best regards, Christoph Michael

Dan McGee

1:27 p.m.

On Tue, Feb 15, 2011 at 7:18 AM, Michael Seiwald wrote:

...

On 02/08/2011 11:02 PM, Dan McGee wrote:

...
...
(4) Signing keys Currently when adding a signed package to the repository with repo-add, the signature of the package itself (generated with the package maintainers’ key) is included into the sync db (as %PGPSIG% field in the desc file of the package). Afterwards, the updated sync db is also signed. Firstly, we are not sure how this should be handled in practice. Will the sync db be signed with a central repository key? Or with one of the developers’ keys? Either way, the package signature in the sync db (%PGPSIG%) adds no additional security value, because when pacman verifies both the package signature and the signature of the sync db, it uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the signatures. But not one key, and how does one verify a package they got that was not in a sync DB? Or in a sync DB managed by someone they may trust less, but packaged by someone they may trust more?

A package not in a sync DB cannot be verified - regardless of keeping the package signature in the sync db. If the sync DB is signed, the hash of the package file is sufficient to verify its integrity. The only way allowing for the verification of packages which are not part of the sync DB I can think of would be to somehow make the packages contain the signatures (like RPM packages).

I am not following this point whatsoever. RPM package containing signature == zip of signature + package contents in another zip. There is no added security benefit of this that I can possibly see over package + detached signature- the only thing they are doing is tying it up with some ugly rope and shipping it to you as one file. And the hash of the package file is not at all enough to verify integrity! For one, md5 is not secure, and we've never pretended this is supposed to be anything more than a quick download check. Second, you have continued to run around the issue I stated where not all packages are in a sync repository- drop your "If" clause and your whole point falls down. Your other point, "A package not in a sync DB cannot be verified", is also unclear- can you please elaborate? -Dan

Michael Seiwald

6:57 p.m.

On 02/15/2011 02:27 PM, Dan McGee wrote:

...

On Tue, Feb 15, 2011 at 7:18 AM, Michael Seiwald wrote:

...
On 02/08/2011 11:02 PM, Dan McGee wrote:

...
...
(4) Signing keys Currently when adding a signed package to the repository with repo-add, the signature of the package itself (generated with the package maintainers’ key) is included into the sync db (as %PGPSIG% field in the desc file of the package). Afterwards, the updated sync db is also signed. Firstly, we are not sure how this should be handled in practice. Will the sync db be signed with a central repository key? Or with one of the developers’ keys? Either way, the package signature in the sync db (%PGPSIG%) adds no additional security value, because when pacman verifies both the package signature and the signature of the sync db, it uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the signatures. But not one key, and how does one verify a package they got that was not in a sync DB? Or in a sync DB managed by someone they may trust less, but packaged by someone they may trust more?

A package not in a sync DB cannot be verified - regardless of keeping the package signature in the sync db. If the sync DB is signed, the hash of the package file is sufficient to verify its integrity. The only way allowing for the verification of packages which are not part of the sync DB I can think of would be to somehow make the packages contain the signatures (like RPM packages).

I am not following this point whatsoever.

RPM package containing signature == zip of signature + package contents in another zip. There is no added security benefit of this that I can possibly see over package + detached signature- the only thing they are doing is tying it up with some ugly rope and shipping it to you as one file.

And the hash of the package file is not at all enough to verify integrity! For one, md5 is not secure, and we've never pretended this is supposed to be anything more than a quick download check. Second, you have continued to run around the issue I stated where not all packages are in a sync repository- drop your "If" clause and your whole point falls down.

Your other point, "A package not in a sync DB cannot be verified", is also unclear- can you please elaborate?

-Dan

If the hash of the package file can be verified through the sync DB and a secure hash algorithm is used (e.g. SHA256, SHA512) then the hash _is_ enough to verify the packages' integrity. In fact when using PGP you always sign the hash of the input data, not the whole data itself which would be slow and produces very large signatures. Of course if you want to verify packages which are not part of the sync DB you can only verify them if there is either a detached signature or if the signature is somehow part of the package. The problem that I see with a detached signature is that the user has to download two files manually to verify the packages' integrity. I think that especially inexperienced users might just download the tarball and install it anyway. What I meant by "A package not in a sync DB cannot be verified" is that the current implementation adds the base64-encoded signatures to the sync DB so if the packages is not part of the sync DB (e.g. because it's outdated) how can it be verified in the current scenario? Or maybe I am missing something. Best regards, Michael

Allan McRae

9 p.m.

On 16/02/11 04:57, Michael Seiwald wrote:

...

On 02/15/2011 02:27 PM, Dan McGee wrote:

...
On Tue, Feb 15, 2011 at 7:18 AM, Michael Seiwald wrote:

...
On 02/08/2011 11:02 PM, Dan McGee wrote:

...
...
(4) Signing keys Currently when adding a signed package to the repository with repo-add, the signature of the package itself (generated with the package maintainers’ key) is included into the sync db (as %PGPSIG% field in the desc file of the package). Afterwards, the updated sync db is also signed. Firstly, we are not sure how this should be handled in practice. Will the sync db be signed with a central repository key? Or with one of the developers’ keys? Either way, the package signature in the sync db (%PGPSIG%) adds no additional security value, because when pacman verifies both the package signature and the signature of the sync db, it uses one single keyring (/etc/pacman.d/gnupg/pupring.gpg) for all the signatures. But not one key, and how does one verify a package they got that was not in a sync DB? Or in a sync DB managed by someone they may trust less, but packaged by someone they may trust more?

A package not in a sync DB cannot be verified - regardless of keeping the package signature in the sync db. If the sync DB is signed, the hash of the package file is sufficient to verify its integrity. The only way allowing for the verification of packages which are not part of the sync DB I can think of would be to somehow make the packages contain the signatures (like RPM packages).

I am not following this point whatsoever.

RPM package containing signature == zip of signature + package contents in another zip. There is no added security benefit of this that I can possibly see over package + detached signature- the only thing they are doing is tying it up with some ugly rope and shipping it to you as one file.

And the hash of the package file is not at all enough to verify integrity! For one, md5 is not secure, and we've never pretended this is supposed to be anything more than a quick download check. Second, you have continued to run around the issue I stated where not all packages are in a sync repository- drop your "If" clause and your whole point falls down.

Your other point, "A package not in a sync DB cannot be verified", is also unclear- can you please elaborate?

-Dan

If the hash of the package file can be verified through the sync DB and a secure hash algorithm is used (e.g. SHA256, SHA512) then the hash _is_ enough to verify the packages' integrity. In fact when using PGP you always sign the hash of the input data, not the whole data itself which would be slow and produces very large signatures.

Of course if you want to verify packages which are not part of the sync DB you can only verify them if there is either a detached signature or if the signature is somehow part of the package. The problem that I see with a detached signature is that the user has to download two files manually to verify the packages' integrity. I think that especially inexperienced users might just download the tarball and install it anyway.

The current implementation attempts to locate a signature file from alongside a package when installing using pacman -U. Note that pacman -U works with both local and remote packages. So that is automated from a users perspective.

...

What I meant by "A package not in a sync DB cannot be verified" is that the current implementation adds the base64-encoded signatures to the sync DB so if the packages is not part of the sync DB (e.g. because it's outdated) how can it be verified in the current scenario? Or maybe I am missing something.

That is correct. But it is both a good and bad thing... e.g. it means that packages replaced due to a major security flaw are no longer signed. Allan

4911

Age (days ago)

4918

Last active (days ago)

List overview

Download

8 comments

4 participants

participants (4)

Allan McRae
Dan McGee
Denis A. Altoé Falqueto
Michael Seiwald