February 2011 - Pacman-dev - lists.archlinux.org

[pacman-dev] [ Package Signing ] Your signature please
by IgnorantGuru 20 Feb '11

20 Feb '11

Greetings - I was directed to this list as the place where stuff is getting done on package signing. I would like to share some thoughts on this which I hope you'll give some serious consideration. One, I would like to convince you to change your order of operations slightly to the benefit of both users and developers, and two I would like to share some thoughts on open security approaches. First, thanks to Allan and the others who have put some real effort into making this a reality. Nevertheless it is proceeding very slowly and from what I gather is not being given much priority. Obviously that's because the devs don't feel it is worthy of priority. So be it. But if you're going to proceed this slowly with it, please consider changing your order of operations so we users can help ourselves. Specifically, please put providing signatures first, even before your automated signature checking or your final design is complete. If you need to later change how the signatures are stored or keys or other details, that's fine. But get the packages signed and get the signatures onto the mirrors in some usable form. You're currently having armchair debates about arcane replay attacks while the data on the servers is sitting there completely unprotected, and users have no way of verifying its authenticity. Just getting the signatures out there will improve security by several orders of magnitude. The threat is not just a matter of data integrity on the mirrors, but providing a way for users to verify data coming over their networks, from shared caches, stored locally, etc. As one commenter on my blog expressed: "I think you’ve motivated me to try another Linux distribution after years with Ubuntu. You’ve interested me in Arch too, but there is no way I’m going to install it on my desktop, let alone server before they implement package signing. Their mailing list suggests that this is a milestone of not so near future. Unsigned package installation is a security breach of cyclopic proportions, anyone who hacks your old wifi AP will be able to inject malicious Arch packages by repository proxying, this isn’t even possible with Windows updates." And repository proxying is just one of a whole host of security issues unsigned packages create, which have nothing to do with the security of the mirrors. It's a local thing. Arch is depending on very flimsy security through obscurity at this point - hoping no one will go to the trouble - and providing no options to users. If you require the packagers to routinely sign packages now with their keys, get their keys onto key servers, and get the package signatures on the mirrors, at least we have some way of verifying the data. You don't need to rewrite GPG - it's there. I for one would be happy to write a script that scans the pkg cache and checks the sigs. This way when someone says "Arch doesn't have package signing" we can reply "Actually packages ARE signed - we're working on the automatic checking, until then check them yourself". Archers are very good at this sort of thing. But we can't do anything until the sigs are available, and that requires a minimum of effort on your part. It's probably already implemented. And the security precautions you need to take at this point are minimal - just publish the signatures somewhere - they are self-protecting. You don't have to tell anyone what they should do with them or how they are best used - let us worry about that for now. This will also give you the time to get pacman's automated signature checking available on your own timetable, while your servers have some minimal protection (actually quite a bit). Plus instead of rolling out the whole system at once, you'll have the signing and distribution of signatures and keys already in use - perfect for you to test your checking on the real mirrors, and to be exposed to some of the issues that will arise. And you'll have scripts by then which can double-check your checking, so you don't have to feel like everyone's security is on your shoulders alone. As you've probably noticed by now, security development is a high stress endeavor. Break up the load and let problems be found in a more gradual way. Users who have higher security needs or who operate on questionable networks will then have a way to verify their packages. Users who don't want to be bothered can wait until you finish your pacman adjustments. In short, please make the signatures and keys available ASAP. That's great you're working on your security design and automatic checking, taking your time and being careful, but at least give us some sigs for now so we can help ourselves. On the subject of security formats and protocols, I wanted to throw a few ideas in there. First, I think keeping it simple is very important, especially for Arch. I believe any user with GPG should be able to verify a package, no other tools required, and no digging into databases for signatures. Instead of placing signatures in a db file, I think serious thought should be given to using the built-in encapsulation features of GPG. Why have a separate sig file or db mechanism? Wrap the data in the signature - that way it begs to be checked. It can be as simple as package.tar.gz.gpg And checking it can be as simple as manually running the package through GPG. This is very good for security - users can use GPG directly to examine signatures, keyrings, and anomalies. (Pacman in the short term could be adjusted so it simply removes the signature layer without checking.) Also, devs love to make code efficient, but in this area consider not making that your top priority. There are many PGP/GPG libraries which are ill-maintained compared to the long-lived GPG, and they can introduce security problems. They also further remove the user from control of security, which makes for bad security. I suggest having pacman run gpg for its security needs, in a transparent way to the user. No reliance on other libraries. This will have a minor cost in efficiency, but it is a good KISS model and in the long run will improve security. (Many of the PGP APIs were little more than attempts to weaken PGP.) This also makes your job easier. Why reinvent the wheel? The command line does just fine, and gpg gets much more scrutiny in cryptographic circles than the many libraries that allege to duplicate it. Use the real article. When modifying pacman, don't make it overcomplicated. I think users should have some way to specify a custom keyring to be used, and a way to disable or ignore signature checking. Beyond that, keep it minimal and simple. The more complex you make it, the less secure it will be in real world applications. As for replay attacks, you may want to consider this an opportunity to change the way package management is handled more generally. It has some weaknesses that are not based solely in package integrity. If you try to address those weakness with the wrong tools (such as signatures), you're going to create an unnecessarily complex system with compromised security. I suggest making package signatures available now, then working carefully on the overall management system. Change is good. Obviously Arch devs are new to some of these security models, which I believe is one reason you have shown so much reluctance to tackle it. You don't want to mess it up and be embarrassed. Everyone who works in security plays the fool sometimes - ask Phil. Security is very tough and imperfect work compared to many areas of development, cryptographic security especially so. But don't let this reluctance make you choose a total lack of security, which is the current status quo in Arch packaging. Do your best with it, move on, and do your best some more. The weakest link in your security BY FAR will be the key maintenance practices of the packagers, and the security of their personal systems. They should be advised to self-sign their keys, have their keys signed by others, use strong passphrases, not use passphrase caching or convenience tools of any kind, have 6 month expiration dates on keys, and revoke keys routinely anytime local system security may have been compromised. This issue completely blows away replay threat models in severity, and its an imperfect science. You just do your best. But some guidelines should be provided to packagers at some point, and should be enforced where possible. Yet on these issues, please don't debate them before providing signatures to current packages. Get it started, imperfect as it is. If you change keys, file formats, or protocols later, than is not only fine, but such changes should be considered a routine part of the development of Arch's secure package management. Let's get it started.

10 29

[pacman-dev] DRAFT: API changes for pacman-3.5
by Allan McRae 19 Feb '11

19 Feb '11

This is a draft for the README file update for pacman-3.5. I have flagged two areas that I am not particularly clear at what happened. I would be great if the people involved in those changes could make the appropriate adjustments. Allan API CHANGES BETWEEN 3.4 AND 3.5 =============================== [REMOVED] - alpm_db_register_local() - alpm_pkg_has_force() [CHANGED] - interface to pkgcache - alpm_db_get_pkgcache() returns pmpkghash_t - alpm_db_get_pkgcache_list() can be used to get an alpm_list_t interface to the pmpkghash_t - alpm_trans_cb_progress type had some types changed from int to size_t ## HELP!!! - these changes... -int alpm_sync_target(char *target); -int alpm_sync_dbtarget(char *db, char *target); -int alpm_add_target(char *target); -int alpm_remove_target(char *target); +int alpm_add_pkg(pmpkg_t *pkg); +int alpm_remove_pkg(pmpkg_t *pkg); ## HELP!!! - alpm_deptest() is replaced by the more flexibile alpm_find_satisfier() -int alpm_depcmp(pmpkg_t *pkg, pmdepend_t *dep); alpm_list_t *alpm_checkdeps(alpm_list_t *pkglist, int reversedeps, alpm_list_t *remove, alpm_list_t *upgrade); -alpm_list_t *alpm_deptest(pmdb_t *db, alpm_list_t *targets); +pmpkg_t *alpm_find_satisfier(alpm_list_t *pkgs, const char *depstring); +pmpkg_t *alpm_find_dbs_satisfier(alpm_list_t *dbs, const char *depstring); - size_t used for alpm_list_t sizes - return type for alpm_list_count() - parameter type in alpm_list_msort() and alpm_list_nth() [ADDED] - pmpkghash_t struct - alpm_option_get_checkspace(), alpm_option_set_checkspace() - alpm_find_grp_pkgs() - alpm_trans_get_flags() - error codes: PM_ERR_DISK_SPACE, PM_ERR_WRITE - flags PM_TRANS_FLAG_NODEPVERSION, PM_TRANS_EVT_DISKSPACE_START, PM_TRANS_EVT_DISKSPACE_DONE, PM_TRANS_CONV_SELECT_PROVIDER, PM_TRANS_PROGRESS_DISKSPACE_START, PM_TRANS_PROGRESS_INTEGRITY_START

2 1

[pacman-dev] [package signing] Some TODO items implementations
by Denis A. Altoé Falqueto 19 Feb '11

19 Feb '11

Hi, (I tried to compose an opening mail, but git send-mail didn't send it... don't know why) Just some TODO items from the package signing list: https://wiki.archlinux.org/index.php/User:Allan/Package_Signing The patch for makepkg is the merge of two first TODO items for it. Comments are always kindly welcome. -- A: Because it obfuscates the reading. Q: Why is top posting so bad? ------------------------------------------- Denis A. Altoe Falqueto Linux user #524555 -------------------------------------------

1 0

[pacman-dev] Version specs in replaces
by Dan McGee 19 Feb '11

19 Feb '11

So the first command makes sense, and at least right now we parse conflicts like we do depends- we allow version specifiers. However, I found the oddity with REPLACES when doing some archweb work tonight. Should we be allowing this? Should it be restricted to '=' only like provides? I'm not sure, so please chime in. On this note, it would probably be good to make sure we have all the proper definitions nailed down in the manpage, as well as sanity checks in makepkg: depends: name[(=|<|<=|>=|>)version] makedepends: name[(=|<|<=|>=|>)version] (same as depends) checkdepends: name[(=|<|<=|>=|>)version] (same as depends) optdepends: name[(=|<|<=|>=|>)version][: description] (this one is a bit tricky) conflicts: name[(=|<|<=|>=|>)version] (same as depends) provides: name[=version] replaces: name (???) -Dan dmcgee@galway ~/projects/archweb (master) $ zcat /tmp/updaterepos/i686/*.db.tar.gz | grep -A 1 -a CONFLICTS | grep -a '[=><]' | sort | uniq abiword-plugins<2.8.6-4 cloog-ppl<0.15.10-2 dbus<1.2.3-2 gnome-panel<2.31.92 gstreamer0.10-bad<=0.10.17 gtkmm<2.13.0 libx11<1.1.99.2 mesa<7.9 mkinitcpio<0.5.99 mlt++<=0.3.8 nexuiz<2.5.1-3 nvidia-utils<190.42-2 poppler<0.10.5 poppler-qt3<0.16.2 python<3 qt4-doc=4.7.1 tremulous<=1.1.0-5 wesnoth<1.8.5 xf86-video-ati<6.9.0-6 xf86-video-mach64<6.8.2 xf86-video-mga<1.4.11 xf86-video-r128<6.8.1 xf86-video-savage<2.3.1 xf86-video-sis<0.10.2 xf86-video-tdfx<1.4.3 xorg-server<1.9.0 dmcgee@galway ~/projects/archweb (master) $ zcat /tmp/updaterepos/i686/*.db.tar.gz | grep -A 1 -a REPLACES | grep -a '[=><]' | sort | uniq haskell-array<0.3.0.1

4 4

[pacman-dev] [namcap] master git branch updated to use python3
by Rémy Oudompheng 17 Feb '11

17 Feb '11

Hello, If you are using namcap for the main git repository, you are now required to use Python 3 ("python" package) to use it. I have added a unit test for the "rpath" rule, so that the only untested rule is the depends rule. I will add a unit test for that rule before adding any new features to namcap. -- Rémy.

2 3

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.4.3-355-gcfa7602
by dan＠archlinux.org 17 Feb '11

17 Feb '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via cfa760203295e99f65234896036f854b5047c90e (commit) via 00c393d49ff77bb85397278b8f4bd89450402806 (commit) via d1cc1ef6c31dc193adcf48a9aea4a95830c7ae56 (commit) via 62a2e45b12f746c098523782fb5889793ef59687 (commit) via 30f338cce6ebcab5dc521f5effef4c6527e8a197 (commit) from 3afe3b6dfb928200166f348964de24e3f7188568 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit cfa760203295e99f65234896036f854b5047c90e Author: Dan McGee <dan(a)archlinux.org> Date: Wed Feb 16 20:56:32 2011 -0600 Don't generate filelist unless we are going to use it We throw it away if !full, so no need to waste time creating the list in the first place. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 00c393d49ff77bb85397278b8f4bd89450402806 Author: Dan McGee <dan(a)archlinux.org> Date: Wed Feb 16 19:10:53 2011 -0600 Conflict checking code cleanup * Make conflict_isin() static; it is used nowhere else. * Remove does_conflict(): it turns out to be replaceable by a single call to _alpm_depcmp(). By pushing it up, we can reduce calls to _alpm_splitdep() from 60,368 to 16,940 during one test -Su operation I ran. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit d1cc1ef6c31dc193adcf48a9aea4a95830c7ae56 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Feb 15 16:56:44 2011 -0600 Fix some database size estimation problems * Use stat() and not lstat(); we don't care for the size of the symlink if it is one, we want the size of the reference file. * FS#22896, fix local database estimation on platforms that don't abide by the nlink assumption for number of children. * Fix a missing newline on an error message. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 62a2e45b12f746c098523782fb5889793ef59687 Author: Pang Yan Han <pangyanhan(a)gmail.com> Date: Tue Feb 15 06:30:49 2011 +0800 Use CALLOC for _alpm_graph_new() Change _alpm_graph_new() to use CALLOC to avoid explicit zeroing out of fields in pmgraph_t. Signed-off-by: Pang Yan Han <pangyanhan(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 30f338cce6ebcab5dc521f5effef4c6527e8a197 Author: Dan McGee <dan(a)archlinux.org> Date: Fri Feb 11 10:49:30 2011 -0600 diskspace: allow used flag to be toggled for both remove and install Turn it into an enum rather than a boolean, and use a bitmask like we do for reading DB entries. The relevant flag is turned on in our two calculate loops, and anything reading the used flag later can decided which flag (or either) is relevant. This will allow the read-only partition code to be triggered on a remove-only operation, e.g. if /boot was read-only and one tried to remove grub in a sync transaction. Of course, right now, we don't actually run the diskspace check code in the '-R' codepath. Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: lib/libalpm/be_local.c | 32 ++++++++++++++++++++++++++------ lib/libalpm/be_package.c | 2 +- lib/libalpm/be_sync.c | 9 +++++---- lib/libalpm/conflict.c | 43 +++++++++++++------------------------------ lib/libalpm/conflict.h | 1 - lib/libalpm/diskspace.c | 5 +++-- lib/libalpm/diskspace.h | 7 ++++++- lib/libalpm/graph.h | 13 ++----------- lib/libalpm/pkghash.c | 2 +- 9 files changed, 57 insertions(+), 57 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [PATCH] Conflict checking code cleanup
by Dan McGee 17 Feb '11

17 Feb '11

* Make conflict_isin() static; it is used nowhere else. * Remove does_conflict(): it turns out to be replaceable by a single call to _alpm_depcmp(). By pushing it up, we can reduce calls to _alpm_splitdep() from 60,368 to 16,940 during one test -Su operation I ran. Signed-off-by: Dan McGee <dan(a)archlinux.org> --- lib/libalpm/conflict.c | 43 +++++++++++++------------------------------ lib/libalpm/conflict.h | 1 - 2 files changed, 13 insertions(+), 31 deletions(-) diff --git a/lib/libalpm/conflict.c b/lib/libalpm/conflict.c index ca15dbe..8fda7a7 100644 --- a/lib/libalpm/conflict.c +++ b/lib/libalpm/conflict.c @@ -40,7 +40,8 @@ #include "log.h" #include "deps.h" -pmconflict_t *_alpm_conflict_new(const char *package1, const char *package2, const char *reason) +pmconflict_t *_alpm_conflict_new(const char *package1, const char *package2, + const char *reason) { pmconflict_t *conflict; @@ -75,18 +76,18 @@ pmconflict_t *_alpm_conflict_dup(const pmconflict_t *conflict) return(newconflict); } -int _alpm_conflict_isin(pmconflict_t *needle, alpm_list_t *haystack) +static int conflict_isin(pmconflict_t *needle, alpm_list_t *haystack) { alpm_list_t *i; + const char *npkg1 = needle->package1; + const char *npkg2 = needle->package2; ALPM_LOG_FUNC; for(i = haystack; i; i = i->next) { pmconflict_t *conflict = i->data; - char *cpkg1 = conflict->package1; - char *cpkg2 = conflict->package2; - char *npkg1 = needle->package1; - char *npkg2 = needle->package2; + const char *cpkg1 = conflict->package1; + const char *cpkg2 = conflict->package2; if((strcmp(cpkg1, npkg1) == 0 && strcmp(cpkg2, npkg2) == 0) || (strcmp(cpkg1, npkg2) == 0 && strcmp(cpkg2, npkg1) == 0)) { return(1); @@ -96,28 +97,6 @@ int _alpm_conflict_isin(pmconflict_t *needle, alpm_list_t *haystack) return(0); } -/** Check if pkg1 conflicts with pkg2 - * @param pkg1 package we are looking at - * @param conflict name of the possible conflict - * @param pkg2 package to check - * @return 0 for no conflict, non-zero otherwise - */ -static int does_conflict(pmpkg_t *pkg1, const char *conflict, pmpkg_t *pkg2) -{ - const char *pkg1name = alpm_pkg_get_name(pkg1); - const char *pkg2name = alpm_pkg_get_name(pkg2); - pmdepend_t *conf = _alpm_splitdep(conflict); - int match = 0; - - match = _alpm_depcmp(pkg2, conf); - if(match) { - _alpm_log(PM_LOG_DEBUG, "package %s conflicts with %s (by %s)\n", - pkg1name, pkg2name, conflict); - } - _alpm_dep_free(conf); - return(match); -} - /** Adds the pkg1/pkg2 conflict to the baddeps list * @param *baddeps list to add conflict to * @param pkg1 first package @@ -127,7 +106,9 @@ static void add_conflict(alpm_list_t **baddeps, const char *pkg1, const char *pkg2, const char *reason) { pmconflict_t *conflict = _alpm_conflict_new(pkg1, pkg2, reason); - if(conflict && !_alpm_conflict_isin(conflict, *baddeps)) { + _alpm_log(PM_LOG_DEBUG, "package %s conflicts with %s (by %s)\n", + pkg1, pkg2, reason); + if(conflict && !conflict_isin(conflict, *baddeps)) { *baddeps = alpm_list_add(*baddeps, conflict); } else { _alpm_conflict_free(conflict); @@ -158,6 +139,7 @@ static void check_conflict(alpm_list_t *list1, alpm_list_t *list2, for(j = alpm_pkg_get_conflicts(pkg1); j; j = j->next) { const char *conflict = j->data; + pmdepend_t *parsed_conflict = _alpm_splitdep(conflict); for(k = list2; k; k = k->next) { pmpkg_t *pkg2 = k->data; @@ -168,7 +150,7 @@ static void check_conflict(alpm_list_t *list1, alpm_list_t *list2, continue; } - if(does_conflict(pkg1, conflict, pkg2)) { + if(_alpm_depcmp(pkg2, parsed_conflict)) { if(order >= 0) { add_conflict(baddeps, pkg1name, pkg2name, conflict); } else { @@ -176,6 +158,7 @@ static void check_conflict(alpm_list_t *list1, alpm_list_t *list2, } } } + _alpm_dep_free(parsed_conflict); } } } diff --git a/lib/libalpm/conflict.h b/lib/libalpm/conflict.h index 09b4f99..418d3f6 100644 --- a/lib/libalpm/conflict.h +++ b/lib/libalpm/conflict.h @@ -40,7 +40,6 @@ struct __pmfileconflict_t { pmconflict_t *_alpm_conflict_new(const char *package1, const char *package2, const char *reason); pmconflict_t *_alpm_conflict_dup(const pmconflict_t *conflict); void _alpm_conflict_free(pmconflict_t *conflict); -int _alpm_conflict_isin(pmconflict_t *needle, alpm_list_t *haystack); alpm_list_t *_alpm_innerconflicts(alpm_list_t *packages); alpm_list_t *_alpm_outerconflicts(pmdb_t *db, alpm_list_t *packages); alpm_list_t *_alpm_db_find_fileconflicts(pmdb_t *db, pmtrans_t *trans, -- 1.7.4

1 0

[pacman-dev] [PATCH] Timeout when download problems occur
by Dan McGee 16 Feb '11

16 Feb '11

We already set fetchTimeout to 10 seconds, but this does not apply for some of the connection setup steps such as connect(). This left us hanging in a few places where we would normally be stuck in a system call for an indeterminate amount of time. This addresses FS#15369, which has grown to include and duplicate several other bugs and failures such as specifying a non-existent FTP server, DSL disconnections, etc. Signed-off-by: Dan McGee <dan(a)archlinux.org> --- Anyone that wants to look this over, it was pretty simple and kills one of our long-lingering issues before a 3.5.0 release. The output isn't necessarily beautiful, but it at least doesn't hang forever now. I tested this by adding a line like Server = ftp://192.168.4.4/$repo/os/$arch to my /etc/pacman.d/mirrorlist file, and then running pacman -Sy. $ sudo ./src/pacman/pacman -Sy Password: :: Synchronizing package databases... testing is up to date error: failed retrieving file 'core.db' from 192.168.4.4 : Interrupted system call core is up to date error: failed retrieving file 'extra.db' from 192.168.4.4 : Interrupted system call extra is up to date community-testing is up to date error: failed retrieving file 'multilib.db' from 192.168.4.4 : Interrupted system call multilib is up to date error: failed retrieving file 'community.db' from 192.168.4.4 : Interrupted system call community is up to date -Dan lib/libalpm/dload.c | 21 +++++++++++++++++---- 1 files changed, 17 insertions(+), 4 deletions(-) diff --git a/lib/libalpm/dload.c b/lib/libalpm/dload.c index 7a98eb1..44ff17c 100644 --- a/lib/libalpm/dload.c +++ b/lib/libalpm/dload.c @@ -88,10 +88,10 @@ static const char *gethost(struct url *fileurl) int dload_interrupted; static void inthandler(int signum) { - dload_interrupted = 1; + dload_interrupted = signum; } -#define check_stop() if(dload_interrupted) { ret = -1; goto cleanup; } +#define check_stop() do { alarm(0); if(dload_interrupted) { ret = -1; goto cleanup; } } while(0) enum sighandlers { OLD = 0, NEW = 1 }; static int download_internal(const char *url, const char *localpath, @@ -102,7 +102,7 @@ static int download_internal(const char *url, const char *localpath, off_t dl_thisfile = 0; ssize_t nread = 0; char *tempfile, *destfile, *filename; - struct sigaction sig_pipe[2], sig_int[2]; + struct sigaction sig_pipe[2], sig_int[2], sig_alrm[2]; off_t local_size = 0; time_t local_time = 0; @@ -169,6 +169,12 @@ static int download_internal(const char *url, const char *localpath, sigaction(SIGINT, NULL, &sig_int[OLD]); sigaction(SIGINT, &sig_int[NEW], NULL); + sig_alrm[NEW].sa_handler = &inthandler; + sigemptyset(&sig_alrm[NEW].sa_mask); + sig_alrm[NEW].sa_flags = 0; + sigaction(SIGALRM, NULL, &sig_alrm[OLD]); + sigaction(SIGALRM, &sig_alrm[NEW], NULL); + /* NOTE: libfetch does not reset the error code, be sure to do it before * calls into the library */ @@ -184,7 +190,9 @@ static int download_internal(const char *url, const char *localpath, * trouble in trying to do both size and "if-modified-since" logic in a * non-stat request, so avoid it. */ fetchLastErrCode = 0; + alarm(fetchTimeout); if(fetchStat(fileurl, &ust, "") == -1) { + alarm(0); pm_errno = PM_ERR_LIBFETCH; _alpm_log(PM_LOG_ERROR, _("failed retrieving file '%s' from %s : %s\n"), filename, gethost(fileurl), fetchLastErrString); @@ -211,6 +219,7 @@ static int download_internal(const char *url, const char *localpath, } fetchLastErrCode = 0; + alarm(fetchTimeout); dlf = fetchGet(fileurl, ""); check_stop(); @@ -252,6 +261,7 @@ static int download_internal(const char *url, const char *localpath, handle->dlcb(filename, 0, ust.size); } + alarm(fetchTimeout); while((nread = fetchIO_read(dlf, buffer, PM_DLBUF_LEN)) > 0) { check_stop(); size_t nwritten = 0; @@ -268,7 +278,9 @@ static int download_internal(const char *url, const char *localpath, if(handle->dlcb) { handle->dlcb(filename, dl_thisfile, ust.size); } + alarm(fetchTimeout); } + alarm(0); /* did the transfer complete normally? */ if (nread == -1) { @@ -333,10 +345,11 @@ cleanup: fetchFreeURL(fileurl); /* restore the old signal handlers */ + sigaction(SIGALRM, &sig_alrm[OLD], NULL); sigaction(SIGINT, &sig_int[OLD], NULL); sigaction(SIGPIPE, &sig_pipe[OLD], NULL); /* if we were interrupted, trip the old handler */ - if(dload_interrupted) { + if(dload_interrupted == SIGINT) { raise(SIGINT); } -- 1.7.4

2 1

[pacman-dev] [PATCH] Use CALLOC for _alpm_graph_new()
by Pang Yan Han 15 Feb '11

15 Feb '11

Change _alpm_graph_new() to use CALLOC to avoid explicit zeroing out of fields in pmgraph_t. Signed-off-by: Pang Yan Han <pangyanhan(a)gmail.com> --- lib/libalpm/graph.h | 10 +--------- 1 files changed, 1 insertions(+), 9 deletions(-) diff --git a/lib/libalpm/graph.h b/lib/libalpm/graph.h index 69f6500..f16d048 100644 --- a/lib/libalpm/graph.h +++ b/lib/libalpm/graph.h @@ -38,15 +38,7 @@ static pmgraph_t *_alpm_graph_new(void) { pmgraph_t *graph = NULL; - MALLOC(graph, sizeof(pmgraph_t), RET_ERR(PM_ERR_MEMORY, NULL)); - - if(graph) { - graph->state = 0; - graph->data = NULL; - graph->parent = NULL; - graph->children = NULL; - graph->childptr = NULL; - } + CALLOC(graph, 1, sizeof(pmgraph_t), RET_ERR(PM_ERR_MEMORY, NULL)); return(graph); } -- 1.7.4

2 1

[pacman-dev] pacman signing security vulnerabilities
by Michael Seiwald 15 Feb '11

15 Feb '11

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

4 8