[arch-general] unrealircd 3.2.8.1-2 contains backdoor
Hi folks, the unrealircd version in community (3.2.8.1-2) has been flagged as containing a backdoor which allows an attacker to execute commands with the privileges of the user running the daemon. The md5sum in the PKGBUILD (abs) matches the known-bad md5sum from this announcement: http://sourceforge.net/mailarchive/message.php?msg_name=4C134F7E.202%40vulns... I've already filed a bug as FS#19780 to the community project, but given the severity I thought it would be wise to alert a wider audience. Greetings, Jinks
Am 13.06.2010 00:57, schrieb Alexander Duscheleit:
Hi folks,
the unrealircd version in community (3.2.8.1-2) has been flagged as containing a backdoor which allows an attacker to execute commands with the privileges of the user running the daemon.
The md5sum in the PKGBUILD (abs) matches the known-bad md5sum from this announcement: http://sourceforge.net/mailarchive/message.php?msg_name=4C134F7E.202%40vulns...
I've already filed a bug as FS#19780 to the community project, but given the severity I thought it would be wise to alert a wider audience.
Maybe you should post to the right list then.
Greetings, Jinks
On Sun, 13 Jun 2010 01:19:02 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.06.2010 00:57, schrieb Alexander Duscheleit:
I've already filed a bug as FS#19780 to the community project, but given the severity I thought it would be wise to alert a wider audience.
Maybe you should post to the right list then.
Isn't that what I did? From the Arch Linux related lists, this one seemed the most appropriate I have post access to. Aur-general doesn't apply, dev-public is read-only, all others don't fit the topic and there is no -security. So which Arch list would have been better?
On 06/13/2010 03:06 AM, Alexander Duscheleit wrote:
On Sun, 13 Jun 2010 01:19:02 +0200 Thomas Bächler<thomas@archlinux.org> wrote:
Am 13.06.2010 00:57, schrieb Alexander Duscheleit:
I've already filed a bug as FS#19780 to the community project, but given the severity I thought it would be wise to alert a wider audience.
Maybe you should post to the right list then.
Isn't that what I did? From the Arch Linux related lists, this one seemed the most appropriate I have post access to. Aur-general doesn't apply, dev-public is read-only, all others don't fit the topic and there is no -security. So which Arch list would have been better?
aur-general is the mailing list for community repo in which trusted users lurk -- Ionuț
Am 13.06.2010 02:06, schrieb Alexander Duscheleit:
On Sun, 13 Jun 2010 01:19:02 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.06.2010 00:57, schrieb Alexander Duscheleit:
I've already filed a bug as FS#19780 to the community project, but given the severity I thought it would be wise to alert a wider audience.
Maybe you should post to the right list then.
Isn't that what I did? From the Arch Linux related lists, this one seemed the most appropriate I have post access to. Aur-general doesn't apply, dev-public is read-only, all others don't fit the topic and there is no -security. So which Arch list would have been better?
aur-general is where all issues concerning community packages can be discussed with the TUs, and it is the only list where every single TU is subscribed. If you didn't notice, I already cross-posted my last reply to aur-general with a full-quote.
On Sun, 13 Jun 2010 02:10:56 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.06.2010 02:06, schrieb Alexander Duscheleit:
On Sun, 13 Jun 2010 01:19:02 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.06.2010 00:57, schrieb Alexander Duscheleit:
I've already filed a bug as FS#19780 to the community project, but given the severity I thought it would be wise to alert a wider audience.
Maybe you should post to the right list then.
Isn't that what I did? From the Arch Linux related lists, this one seemed the most appropriate I have post access to. Aur-general doesn't apply, dev-public is read-only, all others don't fit the topic and there is no -security. So which Arch list would have been better?
aur-general is where all issues concerning community packages can be discussed with the TUs, and it is the only list where every single TU is subscribed.
OK, I really didn't know that. I thought that since the repo moved to the "proper" arch servers, the relation between community and AUR wouldn't apply anymore the way it did before. I'll remeber that for the future. (I saw the crosspost right after I sent my 1st reply.) OTOH the original mail was meant more to alert *users* of unrealircd, the maintainer should actually already have been noticed via the bug. On a side-note, Sergej already has published a new pkgrel this afternoon (2010-06-12 16:40:54 UTC). So the bug is/was already obsolete before I wrote it. (I should remember to check the website before trusting supposedly up to date mirrors I guess.) What do we actually need a -security list for, when maintainers fix vulnerabilities before the are filed? ;-)
Am 13.06.2010 02:33, schrieb Alexander Duscheleit:
OTOH the original mail was meant more to alert *users* of unrealircd, the maintainer should actually already have been noticed via the bug.
In that case, it seems you chose your list wisely.
On a side-note, Sergej already has published a new pkgrel this afternoon (2010-06-12 16:40:54 UTC). So the bug is/was already obsolete before I wrote it.
Good, didn't notice that. I was quite shocked when I read about the issue.
On Sun, 13 Jun 2010 09:58:38 +0200 Thomas Bächler <thomas@archlinux.org> wrote:
Am 13.06.2010 02:33, schrieb Alexander Duscheleit:
OTOH the original mail was meant more to alert *users* of unrealircd, the maintainer should actually already have been noticed via the bug.
In that case, it seems you chose your list wisely.
On a side-note, Sergej already has published a new pkgrel this afternoon (2010-06-12 16:40:54 UTC). So the bug is/was already obsolete before I wrote it.
Good, didn't notice that. I was quite shocked when I read about the issue.
This is the reason why we need package signing for Pacman. I'm aware that some progress has been made and it's being worked on. Are there any updates? Ananda
On 13/06/10 19:38, Ananda Samaddar wrote:
On Sun, 13 Jun 2010 09:58:38 +0200 Thomas Bächler<thomas@archlinux.org> wrote:
Am 13.06.2010 02:33, schrieb Alexander Duscheleit:
OTOH the original mail was meant more to alert *users* of unrealircd, the maintainer should actually already have been noticed via the bug.
In that case, it seems you chose your list wisely.
On a side-note, Sergej already has published a new pkgrel this afternoon (2010-06-12 16:40:54 UTC). So the bug is/was already obsolete before I wrote it.
Good, didn't notice that. I was quite shocked when I read about the issue.
This is the reason why we need package signing for Pacman. I'm aware that some progress has been made and it's being worked on. Are there any updates?
Yes... because package signing magically fixes all upstream issues. Allan
On Sun, 13 Jun 2010 19:48:53 +1000 Allan McRae <allan@archlinux.org> wrote:
This is the reason why we need package signing for Pacman. I'm aware that some progress has been made and it's being worked on. Are there any updates?
Yes... because package signing magically fixes all upstream issues.
Allan
My point was that malicious attackers can add compromise packages to mirrors and alter the repo.db. Package signing would mitigate that. I was attempting to say that what happened in this instance could happen to an Arch mirror or mirrors. There's no need to be rude. Ananda
On Sun, 2010-06-13 at 10:48 +0100, Ananda Samaddar wrote:
On Sun, 13 Jun 2010 19:48:53 +1000 Allan McRae <allan@archlinux.org> wrote:
This is the reason why we need package signing for Pacman. I'm aware that some progress has been made and it's being worked on. Are there any updates?
Yes... because package signing magically fixes all upstream issues.
Allan
My point was that malicious attackers can add compromise packages to mirrors and alter the repo.db. Package signing would mitigate that. I was attempting to say that what happened in this instance could happen to an Arch mirror or mirrors. There's no need to be rude.
Everytime this comes up the response is the same. Package signing will only be a big deal if enough people are willing to get coding to implement it. Necessity is determined by availability, not the other way round. The way I see it, if noone is willing to work on it, it can't be too important in a general sense.
On Sun, Jun 13, 2010 at 11:38 AM, Ananda Samaddar <ananda@samaddar.co.uk> wrote:
This is the reason why we need package signing for Pacman. I'm aware that some progress has been made and it's being worked on. Are there any updates?
It's all there : http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg and there : http://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman Come back to us when everything is implemented and working :) You can also read the last thread : http://mailman.archlinux.org/pipermail/arch-general/2010-April/012897.html And contact Denis A. Altoé Falqueto about pacman-key and all the rest, and maybe Aleksis Jauntēvs too Basically there is no one leading and coordinating these efforts, just various people who pushed it a bit at random time in the past, and got quickly de-motivated by the lack of interest from everyone else.
On Sun, Jun 13, 2010 at 7:46 AM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Sun, Jun 13, 2010 at 11:38 AM, Ananda Samaddar <ananda@samaddar.co.uk> wrote:
This is the reason why we need package signing for Pacman. I'm aware that some progress has been made and it's being worked on. Are there any updates?
It's all there : http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg and there : http://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman
Come back to us when everything is implemented and working :)
You can also read the last thread : http://mailman.archlinux.org/pipermail/arch-general/2010-April/012897.html And contact Denis A. Altoé Falqueto about pacman-key and all the rest, and maybe Aleksis Jauntēvs too
Basically there is no one leading and coordinating these efforts, just various people who pushed it a bit at random time in the past, and got quickly de-motivated by the lack of interest from everyone else.
Yes, it's basically true. I'm ye a little motivated. I just don't have the time right now to do anything. I think I'll push pacman-key and some other things to the project on gitorious (http://gitorious.org/pacman-pkgsig). It is a fork of the sig branch of Allan's git repository, so that we can test things without the need to have commit rights on Allan's repo. Anyway, I'm trying to find some time to work on it as soon as possible, but I can't promise anything. This is my first time working with C in a big implementation, so this is other problem to deal with. And keep in mind that package signing per se will not solve this kind of problems. Repository database signing is more important for that solution, but is a problem in the current workflow of Arch developers. -- ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Mon, 14 Jun 2010, Denis A. Altoé Falqueto wrote:
And keep in mind that package signing per se will not solve this kind of problems. Repository database signing is more important for that solution, but is a problem in the current workflow of Arch developers.
How exactly is core and extra database populated? Moreover, instead of building all packages in the private PCs of developers, I think it is preferable to submit PKGBUILDs to build servers (via web interface maybe) and let the servers do the build + signing + repoupdate... That way if a developer's system gets compromised his packages will stay clean. Of course that needs extra work and equipment, but perhaps we can agree to it as a future target. On another note, an easy but maybe a bit costly way to avoid any MITM tampering to packages, is serve *.md5 files for every package through a trusted HTTPS host. Then everyone can query that single host and check if the package he got from a mirror is safe. Costs: A little more traffic by serving hash files to everyone plus the cost of the certificate from a CA. Is the income Arch receives from ads and schwag enough for such a simple solution? Dimitris
How exactly is core and extra database populated? Moreover, instead of building all packages in the private PCs of developers Packages are not build on developers computers but on build machines as explained here http://wiki.archlinux.org/index.php/Pacbuild
<http://wiki.archlinux.org/index.php/Pacbuild>There is also an implementation of package signing in pacman on the link Xavier provided some emails up on this conversation. I don't think there is any need to re-think it all. Just need to be tested. I am currently trying to set up a build system on my box and will then try to use these patches to provide feedback. On 15 June 2010 15:57, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Mon, 14 Jun 2010, Denis A. Altoé Falqueto wrote:
And keep in mind that package signing per se will not solve this kind of problems. Repository database signing is more important for that solution, but is a problem in the current workflow of Arch developers.
How exactly is core and extra database populated?
Moreover, instead of building all packages in the private PCs of developers, I think it is preferable to submit PKGBUILDs to build servers (via web interface maybe) and let the servers do the build + signing + repoupdate... That way if a developer's system gets compromised his packages will stay clean. Of course that needs extra work and equipment, but perhaps we can agree to it as a future target.
On another note, an easy but maybe a bit costly way to avoid any MITM tampering to packages, is serve *.md5 files for every package through a trusted HTTPS host. Then everyone can query that single host and check if the package he got from a mirror is safe.
Costs: A little more traffic by serving hash files to everyone plus the cost of the certificate from a CA. Is the income Arch receives from ads and schwag enough for such a simple solution?
Dimitris
On Tue, Jun 15, 2010 at 8:58 AM, Guillaume ALAUX <guillaume@alaux.net> wrote:
How exactly is core and extra database populated? Moreover, instead of building all packages in the private PCs of developers Packages are not build on developers computers but on build machines as explained here http://wiki.archlinux.org/index.php/Pacbuild
Pacbuild hasn't been touched for years... -Dan
On 15 June 2010 16:46, Dan McGee <dpmcgee@gmail.com> wrote:
On Tue, Jun 15, 2010 at 8:58 AM, Guillaume ALAUX <guillaume@alaux.net> wrote:
How exactly is core and extra database populated? Moreover, instead of building all packages in the private PCs of developers Packages are not build on developers computers but on build machines as explained here http://wiki.archlinux.org/index.php/Pacbuild
Pacbuild hasn't been touched for years...
-Dan
Pacbuild hasn't been touched for years... Yes I have had (and actually still have) some issues setting up the complete build system but I try to get the wiki page up to date
On 06/15/2010 04:57 PM, Dimitrios Apostolou wrote:
On Mon, 14 Jun 2010, Denis A. Altoé Falqueto wrote:
And keep in mind that package signing per se will not solve this kind of problems. Repository database signing is more important for that solution, but is a problem in the current workflow of Arch developers.
How exactly is core and extra database populated?
repo-add reponame.db.tar.gz packagefile. on the server we have db-core/extra/testing, which checkouts the package build from svn, compare the version and then copy into the directory and running repo-add
Moreover, instead of building all packages in the private PCs of developers, I think it is preferable to submit PKGBUILDs to build servers (via web interface maybe) and let the servers do the build + signing + repoupdate... That way if a developer's system gets compromised his packages will stay clean. Of course that needs extra work and equipment, but perhaps we can agree to it as a future target.
i found this annoying since, debugging is more harder, i have to download the resulted package to test it, send it, wait for the pool to come. is a mess :D even if my system is compromised, we build our packages in clean chroots. -- Ionuț
On Tue, 15 Jun 2010, Ionuț Bîru wrote:
i found this annoying since, debugging is more harder, i have to download the resulted package to test it, send it, wait for the pool to come. is a mess :D
even if my system is compromised, we build our packages in clean chroots.
The workflow won't be changing much using a build server: you build and rebuild on your own system using a clean chroot, until you are satisfied with the result. Then you submit PKGBUILD to the build server and forget about it. 99% of the time the build will be successful, since it uses the exact same buildchroot you did, the package will be automatically signed with the arch-wide key stored safely in the server and will be submitted to the repo. 1% of the time something bad happens in the process and you get notified by email... I think the idea of build server is only positive, if we somehow find the equipment needed. :-) Dimitris
On Tue, Jun 15, 2010 at 10:57 AM, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Mon, 14 Jun 2010, Denis A. Altoé Falqueto wrote:
And keep in mind that package signing per se will not solve this kind of problems. Repository database signing is more important for that solution, but is a problem in the current workflow of Arch developers.
How exactly is core and extra database populated?
Moreover, instead of building all packages in the private PCs of developers, I think it is preferable to submit PKGBUILDs to build servers (via web interface maybe) and let the servers do the build + signing + repoupdate... That way if a developer's system gets compromised his packages will stay clean. Of course that needs extra work and equipment, but perhaps we can agree to it as a future target.
Well, in fact, that is the very problem we have. The repository database files are created remotely and I think that we should avoid signing files remotely. In fact, a dev's machine is less visible than the servers of Arch. And sse the response from Ionut too. I was thinking (see the wiki page for details) in a way to break the creation of the repo db files in two stages. It probably will be transparent for the developers. One stage creates the db file and the other signs, but that must be done locally. I think that creating an MD5 checksum and signing just that can be a solution. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Tue, 15 Jun 2010, Denis A. Altoé Falqueto wrote:
On Tue, Jun 15, 2010 at 10:57 AM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Moreover, instead of building all packages in the private PCs of developers, I think it is preferable to submit PKGBUILDs to build servers (via web interface maybe) and let the servers do the build + signing + repoupdate... That way if a developer's system gets compromised his packages will stay clean. Of course that needs extra work and equipment, but perhaps we can agree to it as a future target.
Well, in fact, that is the very problem we have. The repository database files are created remotely and I think that we should avoid signing files remotely. In fact, a dev's machine is less visible than the servers of Arch. And sse the response from Ionut too.
Let me just clarify here that by "build server" I mean a machine where developers have *not* shell access (and in fact almost nobody has), and by "package signing" I mean signing with a specific archlinux key which is unknown (the private part) to most devs. Some distros follow that approach to security. What you are proposing is package signing by developer keys, that's a different approach. I am just bringing up alternatives. Dimitris BTW I don't think that building inside a compromised system is in any way secure, even if building inside a chroot.
On 15 June 2010 16:55, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Tue, 15 Jun 2010, Denis A. Altoé Falqueto wrote:
On Tue, Jun 15, 2010 at 10:57 AM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Moreover, instead of building all packages in the private PCs of developers, I think it is preferable to submit PKGBUILDs to build servers (via web interface maybe) and let the servers do the build + signing + repoupdate... That way if a developer's system gets compromised his packages will stay clean. Of course that needs extra work and equipment, but perhaps we can agree to it as a future target.
Well, in fact, that is the very problem we have. The repository database files are created remotely and I think that we should avoid signing files remotely. In fact, a dev's machine is less visible than the servers of Arch. And sse the response from Ionut too.
Let me just clarify here that by "build server" I mean a machine where developers have *not* shell access (and in fact almost nobody has), and by "package signing" I mean signing with a specific archlinux key which is unknown (the private part) to most devs. Some distros follow that approach to security.
What you are proposing is package signing by developer keys, that's a different approach. I am just bringing up alternatives.
Dimitris
BTW I don't think that building inside a compromised system is in any way secure, even if building inside a chroot.
I think that we should avoid signing files remotely. Is there any precise reason? If it is because "that remote place could be compromised" well any dev computer could be compromized too !
by "package signing" I mean signing with a specific archlinux key which is unknown (the private part) to most devs. This is what is implemented in this git http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg
The diffs I see there (made by Dan and Geoffroy) look good to me. As far as I understand, when a package is built on the (remote) build server, its signature is added to the desc file of the repo and the repo.db.tar.gz is signed itself. When pacman retreives the repo.db.tar.gz, it checks the signatures of this file and then has all packages signatures available in it ! This looks very KISS and elegant to me : no mypackage.pkg.tar.xz.asc lying around in the FTP or (even worse to my opinion) into the pkg tarball. But if you think about using private/public key authentication for devs when submitting packages to the build system then I do agree!
On Tue, Jun 15, 2010 at 12:02 PM, Guillaume ALAUX <guillaume@alaux.net> wrote:
I think that we should avoid signing files remotely. Is there any precise reason? If it is because "that remote place could be compromised" well any dev computer could be compromized too !
The main reason is that we would need to keep a copy of the private key for each sining key in the remote machine. Of course, the private key is encrypted with the passphrase (a good one, if possible). That would mitigate an immediate use of a compromised private key, but with time, it can be cracked and used to sign files on behalf the real owner of the key. You don't want to let the card of your bank account on two places, do you? Even though theoretically only you have the PIN. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Tue, Jun 15, 2010 at 12:34 PM, Denis A. Altoé Falqueto <denisfalqueto@gmail.com> wrote:
On Tue, Jun 15, 2010 at 12:02 PM, Guillaume ALAUX <guillaume@alaux.net> wrote:
I think that we should avoid signing files remotely. Is there any precise reason? If it is because "that remote place could be compromised" well any dev computer could be compromized too !
The main reason is that we would need to keep a copy of the private key for each sining key in the remote machine. Of course, the private key is encrypted with the passphrase (a good one, if possible). That would mitigate an immediate use of a compromised private key, but with time, it can be cracked and used to sign files on behalf the real owner of the key. You don't want to let the card of your bank account on two places, do you? Even though theoretically only you have the PIN.
Just appending this. The proposed model is based on the web of trust. We would trust on some keys to sign other keys. The main keys would be kept by some high trusty developers. They would sign the public keys of the other developers (and their personal keys too) with the main ones. We, mortal users, would trust the main keys to sign the others, and files signed by the developers' keys would be considered valid, by transitivity of the trust model. So, if a developer's key is compromised, it would be enough to generate another, submit to the key signers and resign the packages affected. In the current workflow, the package building is made in chroots, in the machine of each developer (sound reasons given by Ionut, above). The package would be signed after him testing it. The package would be upload to a staging area and the repo.db would be created. At this point, the repo.db should be signed, but exactly how is the real problem. I have some ideas, as explained in the wiki page, but I don't have the time and my skills are not so wonderful. This is done by Debian and Fedora, at least (those were what I've searched. Others may do it the same way). And one more thing: the implementation is not the main concern. The process is. That's why we muse discuss it thoroughly. A good plan will lead to a good and secure implementation. We should not rush anything. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
On Tuesday 15 June 2010 18:47:41 Denis A. Altoé Falqueto wrote:
On Tue, Jun 15, 2010 at 12:34 PM, Denis A. Altoé Falqueto
<denisfalqueto@gmail.com> wrote:
On Tue, Jun 15, 2010 at 12:02 PM, Guillaume ALAUX <guillaume@alaux.net> wrote:
I think that we should avoid signing files remotely.
Is there any precise reason? If it is because "that remote place could be compromised" well any dev computer could be compromized too !
The main reason is that we would need to keep a copy of the private key for each sining key in the remote machine. Of course, the private key is encrypted with the passphrase (a good one, if possible). That would mitigate an immediate use of a compromised private key, but with time, it can be cracked and used to sign files on behalf the real owner of the key. You don't want to let the card of your bank account on two places, do you? Even though theoretically only you have the PIN.
Just appending this.
The proposed model is based on the web of trust. We would trust on some keys to sign other keys. The main keys would be kept by some high trusty developers. They would sign the public keys of the other developers (and their personal keys too) with the main ones. We, mortal users, would trust the main keys to sign the others, and files signed by the developers' keys would be considered valid, by transitivity of the trust model.
So, if a developer's key is compromised, it would be enough to generate another, submit to the key signers and resign the packages affected. In the current workflow, the package building is made in chroots, in the machine of each developer (sound reasons given by Ionut, above). The package would be signed after him testing it. The package would be upload to a staging area and the repo.db would be created. At this point, the repo.db should be signed, but exactly how is the real problem. I have some ideas, as explained in the wiki page, but I don't have the time and my skills are not so wonderful. This is done by Debian and Fedora, at least (those were what I've searched. Others may do it the same way).
I dont think that repo.db should be signed and it is enough to sign only the packages. As I understand so far the only reason to sign repo.db file is to prevent "replay" situations in repos. Maybe it is possible to avoid this by comparing repo.db's between enabled repos in the mirrorlist when doing db sync. Ofcourse the status between repos is not consistent all the time but the situation should be ok if the repos are stable and mantained. If the core.db files does not match then the warning is issued to the user.
And one more thing: the implementation is not the main concern. The process is. That's why we muse discuss it thoroughly. A good plan will lead to a good and secure implementation. We should not rush anything.
I completely agree with this. As someone before said - we can not just throw some code at people and make them think that everything is secure now. -- Aleksis Jauntēvs
On Tue, 15 Jun 2010 19:23:14 +0300, Aleksis Jauntēvs <aleksis.jauntevs@gmail.com> wrote:
I dont think that repo.db should be signed and it is enough to sign only the packages. As I understand so far the only reason to sign repo.db file is to prevent "replay" situations in repos.
It's the other way round: signing the DB is important while signing single packages is not (but should still be done for some reasons). If the DB is not signed I could simply add additional packages or replace packages. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Tuesday 15 June 2010 19:37:00 Pierre Schmitz wrote:
On Tue, 15 Jun 2010 19:23:14 +0300, Aleksis Jauntēvs
<aleksis.jauntevs@gmail.com> wrote:
I dont think that repo.db should be signed and it is enough to sign only the packages. As I understand so far the only reason to sign repo.db file is to prevent "replay" situations in repos.
It's the other way round: signing the DB is important while signing single packages is not (but should still be done for some reasons).
If the DB is not signed I could simply add additional packages or replace packages.
Yes, but if we compare the repo.db's with other mirrors then we could tell that this has happened. -- Aleksis Jauntēvs
On Tue, Jun 15, 2010 at 11:43 AM, Aleksis Jauntēvs <aleksis.jauntevs@gmail.com> wrote:
On Tuesday 15 June 2010 19:37:00 Pierre Schmitz wrote:
On Tue, 15 Jun 2010 19:23:14 +0300, Aleksis Jauntēvs
<aleksis.jauntevs@gmail.com> wrote:
I dont think that repo.db should be signed and it is enough to sign only the packages. As I understand so far the only reason to sign repo.db file is to prevent "replay" situations in repos.
It's the other way round: signing the DB is important while signing single packages is not (but should still be done for some reasons).
If the DB is not signed I could simply add additional packages or replace packages.
Yes, but if we compare the repo.db's with other mirrors then we could tell that this has happened.
seems to defeat the purpose when you have to crosscheck everything. nothing is secure unless the entire chain is secure. i'd say give devs their own private keys to sign packages, and have the build server auto sign DB's upon upload of a new package. use detached sigs and push them with the package. use detached sig for the repo, and download it with the db file. if client doesn't understand signatures, it just doesn't download/use them. i think a pacman wrapper could even implement this, as a proof of concept.
Just to clarify the build process that goes on here: 1) make a clean chroot (mkarchroot - only needs done once) 2) build package in chroot (makechrootpkg) 3) upload package to staging area and commit to svn (e.g. testingpkg) 4) release package on master server adding it to repo (e.g. db-testing) Note, no remote build server.... The current code allows: - Signing a package at the end of a build - Adding the package signature to the repo-db - pacman checking that signature The question remains if/how to signing the repo db. Options: - do not sign the repo-db - sign the repo-db with a key kept on the remote server - transfer the repo-db locally and sign the reupload (alternatively, sign a hash). Why exactly is the repo-db needing signed? There is a risk that a mirror could keep updating except for select packages that have exploitable vulnerabilities in them. That would be prevented by repo signing as the mirror would have to update all packages or none. The argument that anybody could just add or replace packages is incorrect as there either would not be a signed package added or it would be signed with a non-trusted signature. I believe there is an option for pacman to enforce package signing for a given repo so I do not see the risk there. Signing directly on the remote server is also probably not the best idea. We know our server has been attacked in the past, so leaving the key to sign the repo database on there is stupid... The repo db sizes are small so transfering them to be signed, and transfering the signature back should be relatively quick. Even quicker once we can convert them to .xz compression (patch already available the release after next). I think that could be implemented by moving the package release (step 4 above) to occur on the developers local machine rather than on the remote server as that would require ssh access only from the developers machine to the master server and not the other way around. That seems more in the realm of devtools/dbscripts requiring changes that makepkg/pacman. Allan
On 16 June 2010 02:23, Allan McRae <allan@archlinux.org> wrote:
Just to clarify the build process that goes on here:
1) make a clean chroot (mkarchroot - only needs done once) 2) build package in chroot (makechrootpkg) 3) upload package to staging area and commit to svn (e.g. testingpkg) 4) release package on master server adding it to repo (e.g. db-testing)
Note, no remote build server....
The current code allows: - Signing a package at the end of a build - Adding the package signature to the repo-db - pacman checking that signature
The question remains if/how to signing the repo db.
Options: - do not sign the repo-db - sign the repo-db with a key kept on the remote server - transfer the repo-db locally and sign the reupload (alternatively, sign a hash).
Why exactly is the repo-db needing signed? There is a risk that a mirror could keep updating except for select packages that have exploitable vulnerabilities in them. That would be prevented by repo signing as the mirror would have to update all packages or none. The argument that anybody could just add or replace packages is incorrect as there either would not be a signed package added or it would be signed with a non-trusted signature. I believe there is an option for pacman to enforce package signing for a given repo so I do not see the risk there.
Signing directly on the remote server is also probably not the best idea. We know our server has been attacked in the past, so leaving the key to sign the repo database on there is stupid...
The repo db sizes are small so transfering them to be signed, and transfering the signature back should be relatively quick. Even quicker once we can convert them to .xz compression (patch already available the release after next). I think that could be implemented by moving the package release (step 4 above) to occur on the developers local machine rather than on the remote server as that would require ssh access only from the developers machine to the master server and not the other way around. That seems more in the realm of devtools/dbscripts requiring changes that makepkg/pacman.
Allan
OK so... Allan, your email makes me realize that I may be using the "wrong" building method. Are the python scripts in the pacbuild package (apple, strawberry, queuepackage, waka and uploadpackage) used any more as described in this page <http://wiki.archlinux.org/index.php/Pacbuild> ? Because some of these scripts point to the old "current" repository we used years ago. And if I understand it right, they don't really fit with what you just said. I guess the current way of building packages involves the devtools package right? Guillaume
On 17/06/10 00:48, Guillaume ALAUX wrote:
Are the python scripts in the pacbuild package (apple, strawberry, queuepackage, waka and uploadpackage) used any more as described in this page<http://wiki.archlinux.org/index.php/Pacbuild> ? Because some of these scripts point to the old "current" repository we used years ago. And if I understand it right, they don't really fit with what you just said.
I have no idea if they were ever actually used... I have been around for a while now, and I never heard of them.
I guess the current way of building packages involves the devtools package right?
yes. mkarchroot and makechrootpkg. Allan
On 17 June 2010 01:34, Allan McRae <allan@archlinux.org> wrote:
On 17/06/10 00:48, Guillaume ALAUX wrote:
Are the python scripts in the pacbuild package (apple, strawberry, queuepackage, waka and uploadpackage) used any more as described in this page<http://wiki.archlinux.org/index.php/Pacbuild> ? Because some of these
scripts point to the old "current" repository we used years ago. And if I understand it right, they don't really fit with what you just said.
I have no idea if they were ever actually used... I have been around for a while now, and I never heard of them.
I guess the current way of building packages involves the devtools package
right?
yes. mkarchroot and makechrootpkg.
Allan
OK Thanks I am going to give devtools a try.
On Tue, 15 Jun 2010, Denis A. Altoé Falqueto wrote:
The proposed model is based on the web of trust. We would trust on some keys to sign other keys. The main keys would be kept by some high trusty developers. They would sign the public keys of the other developers (and their personal keys too) with the main ones. We, mortal users, would trust the main keys to sign the others, and files signed by the developers' keys would be considered valid, by transitivity of the trust model.
So, if a developer's key is compromised, it would be enough to generate another, submit to the key signers and resign the packages affected. In the current workflow, the package building is made in chroots, in the machine of each developer (sound reasons given by Ionut, above). The package would be signed after him testing it. The package would be upload to a staging area and the repo.db would be created. At this point, the repo.db should be signed, but exactly how is the real problem. I have some ideas, as explained in the wiki page, but I don't have the time and my skills are not so wonderful. This is done by Debian and Fedora, at least (those were what I've searched. Others may do it the same way).
As far as I know, Fedora uses a different model: a build server and release-wide keys. Search for "Fedora koji" and "Fedora keys" for more info. However I don't know how do developers submit RPM spec files to the build server, /maybe/ their own keys are used there. About debian I don't have a clue. Dimitris
And one more thing: the implementation is not the main concern. The process is. That's why we muse discuss it thoroughly. A good plan will lead to a good and secure implementation. We should not rush anything.
-- A: Because it obfuscates the reading. Q: Why is top posting so bad?
------------------------------------------- Denis A. Altoe Falqueto -------------------------------------------
Hey, what do you think about this way of verifying packages? On Tue, 15 Jun 2010, Dimitrios Apostolou wrote:
On another note, an easy but maybe a bit costly way to avoid any MITM tampering to packages, is serve *.md5 files for every package through a trusted HTTPS host. Then everyone can query that single host and check if the package he got from a mirror is safe.
Costs: A little more traffic by serving hash files to everyone plus the cost of the certificate from a CA. Is the income Arch receives from ads and schwag enough for such a simple solution?
Let me explain it a bit more: Pacman downloads package-1.tar.xz from a random mirror. It then fetches: https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1 Pacman should then know whether the connection to sums.archlinux.org was tampered, since the certificate is signed from a CA in ca-bundle.crt. So if the two hashes match, the package is safe (as safe as the archlinux server...) That way any type of file can be verified (packages, db files, PKGBUILDs, patches etc) provided that its cryptographic hash is in that HTTPS host. Obviously to be able to verify db files, they need a timestamp appended to them, e.g. core-YYYYMMDDHHMM.tar.gz. That necessary change is perhaps the most difficult part of this proposal. If too many small files is a problem, maybe the whole db.tar.gz can be served (at the cost of a higher bandwidth utilisation). This solution doesn't use package signing nor a web-of-trust. It simply piggybacks on the tried and true HTTPS mechanism. Primary advantage is the lack of complexity which makes it easy to understand and implement. What do you think? Dimitris
On Wed, Jun 16, 2010 at 6:08 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Hey, what do you think about this way of verifying packages?
On Tue, 15 Jun 2010, Dimitrios Apostolou wrote:
On another note, an easy but maybe a bit costly way to avoid any MITM tampering to packages, is serve *.md5 files for every package through a trusted HTTPS host. Then everyone can query that single host and check if the package he got from a mirror is safe.
Costs: A little more traffic by serving hash files to everyone plus the cost of the certificate from a CA. Is the income Arch receives from ads and schwag enough for such a simple solution?
Let me explain it a bit more:
Pacman downloads package-1.tar.xz from a random mirror. It then fetches:
https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1
Pacman should then know whether the connection to sums.archlinux.org was tampered, since the certificate is signed from a CA in ca-bundle.crt. So if the two hashes match, the package is safe (as safe as the archlinux server...)
That way any type of file can be verified (packages, db files, PKGBUILDs, patches etc) provided that its cryptographic hash is in that HTTPS host. Obviously to be able to verify db files, they need a timestamp appended to them, e.g. core-YYYYMMDDHHMM.tar.gz. That necessary change is perhaps the most difficult part of this proposal.
If too many small files is a problem, maybe the whole db.tar.gz can be served (at the cost of a higher bandwidth utilisation).
This solution doesn't use package signing nor a web-of-trust. It simply piggybacks on the tried and true HTTPS mechanism. Primary advantage is the lack of complexity which makes it easy to understand and implement.
What do you think?
I think that someone could blow this apart. I break in, touch a package of my choosing without telling anyone, and update the checksum file. Bam- everyone's systems are fucked and the developers never knew because you didn't do anything both cryptographically secure and verifiable, you just added some indirection to the process. -Dan
On Wed, 16 Jun 2010, Dan McGee wrote:
On Wed, Jun 16, 2010 at 6:08 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Hey, what do you think about this way of verifying packages?
On Tue, 15 Jun 2010, Dimitrios Apostolou wrote:
On another note, an easy but maybe a bit costly way to avoid any MITM tampering to packages, is serve *.md5 files for every package through a trusted HTTPS host. Then everyone can query that single host and check if the package he got from a mirror is safe.
Costs: A little more traffic by serving hash files to everyone plus the cost of the certificate from a CA. Is the income Arch receives from ads and schwag enough for such a simple solution?
Let me explain it a bit more:
Pacman downloads package-1.tar.xz from a random mirror. It then fetches:
https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1
Pacman should then know whether the connection to sums.archlinux.org was tampered, since the certificate is signed from a CA in ca-bundle.crt. So if the two hashes match, the package is safe (as safe as the archlinux server...)
That way any type of file can be verified (packages, db files, PKGBUILDs, patches etc) provided that its cryptographic hash is in that HTTPS host. Obviously to be able to verify db files, they need a timestamp appended to them, e.g. core-YYYYMMDDHHMM.tar.gz. That necessary change is perhaps the most difficult part of this proposal.
If too many small files is a problem, maybe the whole db.tar.gz can be served (at the cost of a higher bandwidth utilisation).
This solution doesn't use package signing nor a web-of-trust. It simply piggybacks on the tried and true HTTPS mechanism. Primary advantage is the lack of complexity which makes it easy to understand and implement.
What do you think?
I think that someone could blow this apart. I break in, touch a package of my choosing without telling anyone, and update the checksum file. Bam- everyone's systems are fucked and the developers never knew because you didn't do anything both cryptographically secure and verifiable, you just added some indirection to the process.
HTTPS is both cryptographically correct and verifiable. The case you mention is if someone breaks the one end, that must be guarded most. The danger is there everywhere, on the web-of-trust case someone that broke into a dev's machine and got the key, can sign anything he wants and serve it to the user, who would know? On the distro-wide key case, it's like someone stealing that key, and be able to serve/sign everything. Here, we don't have a key to keep safe, but a server. So it needs special attention about who has access and how hashes are submitted (although HTTPS can secure this process too). But I admit that keeping a server safe is a bit harder than keys, if that was your point. Dimitris
-Dan
On Wed, Jun 16, 2010 at 6:35 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
On Wed, 16 Jun 2010, Dan McGee wrote:
On Wed, Jun 16, 2010 at 6:08 PM, Dimitrios Apostolou <jimis@gmx.net> wrote:
Hey, what do you think about this way of verifying packages?
On Tue, 15 Jun 2010, Dimitrios Apostolou wrote:
On another note, an easy but maybe a bit costly way to avoid any MITM tampering to packages, is serve *.md5 files for every package through a trusted HTTPS host. Then everyone can query that single host and check if the package he got from a mirror is safe.
Costs: A little more traffic by serving hash files to everyone plus the cost of the certificate from a CA. Is the income Arch receives from ads and schwag enough for such a simple solution?
Let me explain it a bit more:
Pacman downloads package-1.tar.xz from a random mirror. It then fetches:
https://sums.archlinux.org/exactly/the/same/path/package-1.tar.xz.sha1
Pacman should then know whether the connection to sums.archlinux.org was tampered, since the certificate is signed from a CA in ca-bundle.crt. So if the two hashes match, the package is safe (as safe as the archlinux server...)
That way any type of file can be verified (packages, db files, PKGBUILDs, patches etc) provided that its cryptographic hash is in that HTTPS host. Obviously to be able to verify db files, they need a timestamp appended to them, e.g. core-YYYYMMDDHHMM.tar.gz. That necessary change is perhaps the most difficult part of this proposal.
If too many small files is a problem, maybe the whole db.tar.gz can be served (at the cost of a higher bandwidth utilisation).
This solution doesn't use package signing nor a web-of-trust. It simply piggybacks on the tried and true HTTPS mechanism. Primary advantage is the lack of complexity which makes it easy to understand and implement.
What do you think?
I think that someone could blow this apart. I break in, touch a package of my choosing without telling anyone, and update the checksum file. Bam- everyone's systems are fucked and the developers never knew because you didn't do anything both cryptographically secure and verifiable, you just added some indirection to the process.
HTTPS is both cryptographically correct and verifiable. The case you mention is if someone breaks the one end, that must be guarded most. The danger is there everywhere, on the web-of-trust case someone that broke into a dev's machine and got the key, can sign anything he wants and serve it to the user, who would know? On the distro-wide key case, it's like someone stealing that key, and be able to serve/sign everything.
Here, we don't have a key to keep safe, but a server. So it needs special attention about who has access and how hashes are submitted (although HTTPS can secure this process too). But I admit that keeping a server safe is a bit harder than keys, if that was your point.
Yes, I probably should have clarified more. With individual package signing, if a developer's key is cracked, then *only* those packages have to be discarded, not our entire repository. With the above scheme, once you have had a break-in and are unable to know exactly what happened, the entire repository is suspect. Our verifiable server SSL cert means nothing if someone gains access to the machine. The whole idea of there being some universal but well-guarded key is a joke, in my opinion- I definitely do not think that is the right way to approach any signing outside of maybe at the DB level. At the package level, and the way we currently build things, I don't think that makes any sense. -Dan
On Sun, 13 Jun 2010 12:46:09 +0200 Xavier Chantry <chantry.xavier@gmail.com> wrote:
It's all there : http://projects.archlinux.org/users/allan/pacman.git/log/?h=gpg and there : http://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman
Come back to us when everything is implemented and working :)
You can also read the last thread : http://mailman.archlinux.org/pipermail/arch-general/2010-April/012897.html And contact Denis A. Altoé Falqueto about pacman-key and all the rest, and maybe Aleksis Jauntēvs too
Basically there is no one leading and coordinating these efforts, just various people who pushed it a bit at random time in the past, and got quickly de-motivated by the lack of interest from everyone else.
It seems to be actually progressing pretty quickly now and from the other posts on this subject it looks like we may not have to wait too long before it's implemented. Keep up the good work developers! Ananda
participants (14)
-
Aleksis Jauntēvs
-
Alexander Duscheleit
-
Allan McRae
-
Ananda Samaddar
-
C Anthony Risinger
-
Dan McGee
-
Denis A. Altoé Falqueto
-
Dimitrios Apostolou
-
Guillaume ALAUX
-
Ionuț Bîru
-
Ng Oon-Ee
-
Pierre Schmitz
-
Thomas Bächler
-
Xavier Chantry