[pacman-dev] More thought about signature implementation
Hi guys. One more of those long boring emails... sorry. See this situation: let's say we sign packages and the repo.db and the signatures are all dettached, in the same directory as their corresponding files. If some cracker breaks into the machine and deletes the signatures, pacman will not be able to know if the packages and repo.db were signed or not. So, it would be necessary to have some way to indicate that a repository is signed or not and this information must be kept in such a way that an intruder can't change. Another factor to consider is that the signature verification should be optional for each system. I mean, if a user doesn't care about signatures, he should be able to say "pacman, I can't care less about signatures, please". So, I believe that the best place for such information should be in the pacman.conf file, in each repository section. Maybe one cares about signature in one repository but not for another. And we would spread the attack surface for the entire user base, instead of concentrating it only on the server or mirrors. For the repository update, it would be like this: 1. for each repository 1.1. download the repo.db 1.2. if it is signed 1.2.1. download the signature 1.2.2. check the signature 1.3. extract the db to its right place, as today For the package verification, it would be like this: 1. downloads the package 2. if the signature is enabled for the repository 2.1. if the package is signed (this information must come from repo.db) 2.1.1. download the signature for the package 2.1.2. checks the signature For installation of local packages, I am not very worried about signatures. It could be optional, indicated via parameter. Well, I think that to store the new information, we'll have to break the ABI, isn't it? Sorry to say this just a few days after the new release... Maybe we could have put some new fields to future use. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On 19/06/10 03:45, Denis A. Altoé Falqueto wrote:
Hi guys. One more of those long boring emails... sorry.
See this situation: let's say we sign packages and the repo.db and the signatures are all dettached, in the same directory as their corresponding files. If some cracker breaks into the machine and deletes the signatures, pacman will not be able to know if the packages and repo.db were signed or not. So, it would be necessary to have some way to indicate that a repository is signed or not and this information must be kept in such a way that an intruder can't change.
The signatures are currently placed in the repo-db. So only the repo db needs downloaded and not individual signatures. If an attacker deletes the repo database and its signature, that is probably the least of our issues... There will be many copies of a recent signed database that we can recover all the signatures from.
Another factor to consider is that the signature verification should be optional for each system. I mean, if a user doesn't care about signatures, he should be able to say "pacman, I can't care less about signatures, please". So, I believe that the best place for such information should be in the pacman.conf file, in each repository section. Maybe one cares about signature in one repository but not for another. And we would spread the attack surface for the entire user base, instead of concentrating it only on the server or mirrors.
I thought that this was already implemented.
For the repository update, it would be like this:
1. for each repository 1.1. download the repo.db 1.2. if it is signed
(and signature checking is enabled for that repo)
1.2.1. download the signature 1.2.2. check the signature 1.3. extract the db to its right place, as today
For the package verification, it would be like this:
1. downloads the package 2. if the signature is enabled for the repository 2.1. if the package is signed (this information must come from repo.db) 2.1.1. download the signature for the package
No need for that step. The signature is in repo.db
2.1.2. checks the signature
For installation of local packages, I am not very worried about signatures. It could be optional, indicated via parameter.
Agreed.
Well, I think that to store the new information, we'll have to break the ABI, isn't it? Sorry to say this just a few days after the new release... Maybe we could have put some new fields to future use.
Breaking API happens every major release. It is nothing to be very concerned about. Allan
On Sat, Jun 19, 2010 at 12:08 AM, Allan McRae <allan@archlinux.org> wrote:
On 19/06/10 03:45, Denis A. Altoé Falqueto wrote: The signatures are currently placed in the repo-db. So only the repo db needs downloaded and not individual signatures. If an attacker deletes the repo database and its signature, that is probably the least of our issues... There will be many copies of a recent signed database that we can recover all the signatures from.
Hmm, I see. And it is a good idea, indeed. But I've tested two packages (go-openoffice, 130M, and libxfontcache, 8K) to see how this will affect the final size of the database. The size of the signatures was 543 bytes each. So the size of the package will not affect the size of the signatures. What could affect is the key used, given the hash algorithm is the same. My current key has 2024 bits length The table bellow resume the expected increase for each repository: http://pastebin.com/ppfe5dxw Maybe that is acceptable, maybe not. Thinking about it a little, I would not be very glad of having to download almost the same signatures (the ones that didn't change) every time I run pacman -Sy. I believe that just marking if a package is signed inside the repository is enough. Or maybe I've misinterpreted something too.
Another factor to consider is that the signature verification should be optional for each system. I mean, if a user doesn't care about signatures, he should be able to say "pacman, I can't care less about signatures, please". So, I believe that the best place for such information should be in the pacman.conf file, in each repository section. Maybe one cares about signature in one repository but not for another. And we would spread the attack surface for the entire user base, instead of concentrating it only on the server or mirrors.
I thought that this was already implemented.
Good. I am still getting to know the code. Thanks for taking the time to answer. I'm already testing pacman-key and it is working fine. I'll test makepkg and repo-db too, but I believe they are alright. The changes were very little. I've already implemented a function to verify the signatures, in C, using popen to call gpg2. The function was based on a test program I made today, so it is very probably working, at least the basics. On a side note, I discovered a funny thing about apt. They don't use gpgme lib too, but instead call gpgv, a program that just verifies signatures. Looking through its man paage, I learnt that it doesn't respect the web of trust of the keyring (!!!). So, in the end, apt just checks to see if the key is in the keyring (all keys are trustworthy, according to gpgv's manpage) and verifies the file signature. I just didn't have a good feeling about it. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On 19/06/10 14:18, Denis A. Altoé Falqueto wrote:
On Sat, Jun 19, 2010 at 12:08 AM, Allan McRae<allan@archlinux.org> wrote:
On 19/06/10 03:45, Denis A. Altoé Falqueto wrote: The signatures are currently placed in the repo-db. So only the repo db needs downloaded and not individual signatures. If an attacker deletes the repo database and its signature, that is probably the least of our issues... There will be many copies of a recent signed database that we can recover all the signatures from.
Hmm, I see. And it is a good idea, indeed.
But I've tested two packages (go-openoffice, 130M, and libxfontcache, 8K) to see how this will affect the final size of the database. The size of the signatures was 543 bytes each. So the size of the package will not affect the size of the signatures. What could affect is the key used, given the hash algorithm is the same. My current key has 2024 bits length The table bellow resume the expected increase for each repository:
Maybe that is acceptable, maybe not. Thinking about it a little, I would not be very glad of having to download almost the same signatures (the ones that didn't change) every time I run pacman -Sy.
It looks like you just too 543 bytes and multiplied it by the number of packages. Can we have compressed numbers? You could test this by making a repo db out of all the packages in your pacman cache using the current repo-add. Then sign all those packages and make a repo db with all those signatures using the gpg branch repo-add. With the next pacman major release, we can switch to .xz compression for the database which gives up a 30% size decrease to work with. Allan
On Sat, Jun 19, 2010 at 1:18 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Sat, Jun 19, 2010 at 12:08 AM, Allan McRae <allan@archlinux.org> wrote:
On 19/06/10 03:45, Denis A. Altoé Falqueto wrote: The signatures are currently placed in the repo-db. So only the repo db needs downloaded and not individual signatures. If an attacker deletes the repo database and its signature, that is probably the least of our issues... There will be many copies of a recent signed database that we can recover all the signatures from.
Hmm, I see. And it is a good idea, indeed.
But I've tested two packages (go-openoffice, 130M, and libxfontcache, 8K) to see how this will affect the final size of the database. The size of the signatures was 543 bytes each. So the size of the package will not affect the size of the signatures. What could affect is the key used, given the hash algorithm is the same. My current key has 2024 bits length The table bellow resume the expected increase for each repository:
I've tested with my local cache. It currently contains 808 packages. i've signed them all and tarred without compression and with gzip, bzip2 and lzma to see what gives: All the signatures are the same size (543 bytes each). tar: 1200 K tar.gz: 444 K tar.bz2 425 K tar.xz: 428 K Assuming that we'll only store 1/3 of the total size of the signatures, the new table gets: http://pastebin.com/BNwd1MAf The sizes are in KB and the final size of db is the current plus the size of the compacted signatures. Looking at that table now, it could be feasible, at least for the user. There'll be an increase in bandwidth consumption too, because every time someone syncs his databases, almost the same signatures are being served... PS: I saw your email while i was writing this, and i'll test makepkg and repo-add maybe this weekend. Will sure try with my database cache to see the numbers. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Fri, Jun 18, 2010 at 11:51 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Sat, Jun 19, 2010 at 1:18 AM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Sat, Jun 19, 2010 at 12:08 AM, Allan McRae <allan@archlinux.org> wrote:
On 19/06/10 03:45, Denis A. Altoé Falqueto wrote: The signatures are currently placed in the repo-db. So only the repo db needs downloaded and not individual signatures. If an attacker deletes the repo database and its signature, that is probably the least of our issues... There will be many copies of a recent signed database that we can recover all the signatures from.
Hmm, I see. And it is a good idea, indeed.
But I've tested two packages (go-openoffice, 130M, and libxfontcache, 8K) to see how this will affect the final size of the database. The size of the signatures was 543 bytes each. So the size of the package will not affect the size of the signatures. What could affect is the key used, given the hash algorithm is the same. My current key has 2024 bits length The table bellow resume the expected increase for each repository:
I've tested with my local cache. It currently contains 808 packages. i've signed them all and tarred without compression and with gzip, bzip2 and lzma to see what gives: All the signatures are the same size (543 bytes each).
tar: 1200 K tar.gz: 444 K tar.bz2 425 K tar.xz: 428 K
Assuming that we'll only store 1/3 of the total size of the signatures, the new table gets:
The sizes are in KB and the final size of db is the current plus the size of the compacted signatures. Looking at that table now, it could be feasible, at least for the user. There'll be an increase in bandwidth consumption too, because every time someone syncs his databases, almost the same signatures are being served...
Honestly you're worried about a non-issue here. The size of the DBs is fine before and after, and we already serve up 98% of the same info every time someone downloads a DB; package signatures are not that different from any other field already there. -Dan
On Sat, Jun 19, 2010 at 10:47 AM, Dan McGee <dpmcgee@gmail.com> wrote:
Honestly you're worried about a non-issue here. The size of the DBs is fine before and after, and we already serve up 98% of the same info every time someone downloads a DB; package signatures are not that different from any other field already there.
Alright. I'm not really worried, just wanted to discuss it now, before someone comes to nag. To me it is fine and have advantages too. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
participants (3)
-
Allan McRae
-
Dan McGee
-
Denis A. Altoé Falqueto