December 2008 - Pacman-dev - lists.archlinux.org

[pacman-dev] [PATCH] makepkg: save and restore shell options before and after build()
by Dan McGee 05 Dec '08

05 Dec '08

Fix the issue uncovered by FS#12344. In this instance, the dotglob shopt was being set in the build() function but never cleared, causing issues in the remaining parts of the makepkg script. Signed-off-by: Dan McGee <dan(a)archlinux.org> --- scripts/makepkg.sh.in | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 4cc255c..25e4cc8 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -675,6 +675,8 @@ run_build() { # ensure all necessary build variables are exported export CFLAGS CXXFLAGS MAKEFLAGS CHOST + # save our shell options so build() can't override what we need + local $shellopts=$(shopts -p) local ret=0 if [ "$LOGGING" = "1" ]; then @@ -695,6 +697,8 @@ run_build() { else build 2>&1 || ret=$? fi + # reset our shell options + eval "$shellopts" if [ $ret -gt 0 ]; then error "$(gettext "Build Failed.")" -- 1.6.0.4

3 4

[pacman-dev] [translation] Update Italian translation
by Giovanni Scafora 04 Dec '08

04 Dec '08

Hi guys, there is an update Italian translation of pacman. Thanks. -- Arch Linux Developer (voidnull) AUR & Pacman Italian Translations Microdia Developer http://www.archlinux.it

1 0

[pacman-dev] [PATCH] contirb/pactree: fix option parsing
by Allan McRae 04 Dec '08

04 Dec '08

The option parsing was catching any "-d" in an arguement so packages with this in their name did not work. Also removed commented code line that appears to be inserted during testing Signed-off-by: Allan McRae <allan(a)archlinux.org> --- contrib/pactree | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/contrib/pactree b/contrib/pactree index d9fa8b3..df53671 100755 --- a/contrib/pactree +++ b/contrib/pactree @@ -208,11 +208,10 @@ for (( n=0 ; n < $len_options ; n++ )); do continue fi - if [[ "${options[$n]}" =~ -d[[:digit:]]* || "${options[$n]}" == "--depth" ]]; then + if [[ "${options[$n]}" =~ -d[[:digit:]]+ || "${options[$n]}" == "--depth" ]]; then if [[ "${options[$n]#-d}" =~ [[:digit:]]+ ]]; then max_depth="${options[$n]#-d}" elif [[ ${options[$((n+1))]} =~ [[:digit:]]+ ]]; then -# if [ ${options[$((n+1))]} -eq ${options[$((n+1))]} 2>/dev/null ]; then max_depth="${options[$((n+1))]}" unset options[$((n+1))] ((++n)) -- 1.6.0.4

2 1

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.2.1-22-ga1f7c83
by dan＠archlinux.org 03 Dec '08

03 Dec '08

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, maint has been updated via a1f7c83dbf3bce492163362d2896e3a4176be616 (commit) via 6d8a6aef094c162f46a8b9be6a118a502fabca61 (commit) via b99bebc008dcf944a88f99bb44ac9029557e4149 (commit) from a50b067470a8046dabdff66f6266d2208b2f8372 (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 ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: PKGBUILD.proto | 1 + lib/libalpm/be_files.c | 5 ++++- lib/libalpm/delta.c | 15 +++++++++++++++ src/pacman/callback.c | 1 + 4 files changed, 21 insertions(+), 1 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.2.1-52-g61c6552
by dan＠archlinux.org 03 Dec '08

03 Dec '08

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 61c6552862345cb155903cd1566f1cef5c527a94 (commit) via a1f7c83dbf3bce492163362d2896e3a4176be616 (commit) via 6d8a6aef094c162f46a8b9be6a118a502fabca61 (commit) via b99bebc008dcf944a88f99bb44ac9029557e4149 (commit) via a50b067470a8046dabdff66f6266d2208b2f8372 (commit) via 346139298bc547d1cbeb5d41f2067577b96ff1fa (commit) via f7192b595881103f145a118d63d1b342ffd740b4 (commit) from 9394f229a0328228e810b7d4588b24643b42df6a (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 61c6552862345cb155903cd1566f1cef5c527a94 Merge: 9394f229a0328228e810b7d4588b24643b42df6a a1f7c83dbf3bce492163362d2896e3a4176be616 Author: Dan McGee <dan(a)archlinux.org> Date: Tue Dec 2 22:15:02 2008 -0600 Merge branch 'maint' Conflicts: lib/libalpm/dload.c ----------------------------------------------------------------------- Summary of changes: PKGBUILD.proto | 1 + lib/libalpm/be_files.c | 11 +++++++---- lib/libalpm/delta.c | 15 +++++++++++++++ lib/libalpm/dload.c | 10 ++++------ scripts/makepkg.sh.in | 2 +- src/pacman/callback.c | 1 + src/pacman/pacman.c | 46 ++++++++++++++++++++++++++++++++++------------ src/pacman/sync.c | 3 ++- 8 files changed, 65 insertions(+), 24 deletions(-) hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [PATCH] Add optdepends to PKGBUILD.proto
by Allan McRae 03 Dec '08

03 Dec '08

Signed-off-by: Allan McRae <allan(a)archlinux.org> --- PKGBUILD.proto | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/PKGBUILD.proto b/PKGBUILD.proto index 3265530..eddcf75 100644 --- a/PKGBUILD.proto +++ b/PKGBUILD.proto @@ -14,6 +14,7 @@ license=('GPL') groups=() depends=() makedepends=() +optdepends=() provides=() conflicts=() replaces=() -- 1.6.0.4

2 1

[pacman-dev] Package/database signing
by Gerhard Brauer 02 Dec '08

02 Dec '08

(I hope i don't triple-post this mail, sorry) Hi, i took this mail from arch-dev-public and arch-general discussion about "Can we trust our mirrors" Am Mon, 1 Dec 2008 11:06:02 -0600 schrieb "Aaron Griffin" <aaronmgriffin(a)gmail.com>: > > There's too much talk on this idea. Before we go ahead and do this, > could someone submit this patch to the pacman-dev list, so the pacman > developers can give it a once-over. Just make sure to let them know > that this is a temporary solution. I attach my patch to repo-add and a pacman download script to explain how things *could* be done. A proof of concept, working and tested on my local repo. > Additionally - where will gpg get the key from on gerolde? Shouldn't > this be configurable, or even set via an optarg to the -s param? In my environment the signing key is getting from my sec-keyring, cause i start repo-add under my UID. It's the default key in gpg.conf if you have more than one key. And of cource: on gpg command line the key could be selected by several criteria, also from a special keyring. Keyring or keys must kept secure of cource, so mostly the are in $HOME/.gpg This is only a concept for signing the package db for the repos. These database files are created only on gerolde (?) an should be signed only there and from the process which creates the database. This is repo-add. #Q: Which key, where does it come from, how to prevent this key(s)? I would assume only one secret key for database signing. AFAIK from Pierre repo-add is under normal procedures not called directly by the developers, only from upload/build scripts. So one solution maybe: create a dedicated user. repo-add then is running *only* under this UID. The secret key could be in the $HOME of this user, so it's secured from other access. Only god mode users on gerolde could "see" it, and maintain it (revoke, renew, etc.). In the scripts which called repo-add (or if single users must call repo-add directly) we could call it with su or sudo. Without special key selecting then the key is took from $repo-add-userid's keyring and cause it's the only keys it is automatically the default key. #Q: How to implement this in pacman on users side? In my test i use the pacman.conf option XferCommand and a special download script for. I call it like this: XferCommand = /tmp/pacsigdl %o %u Each download is checked if this is a *.db.tar,gz. If yes, the file is verified with the public key part from above. If verification is ok then pacman continues with this db file as usual, if verification failed pacman ignores the downloaded (corrupted) file and signals this for this special repo db (but continues with the rest of a -Syu). No new database for a repo -> no new packages to download/install. That way with XferCommand is not a real solution: a) It makes pacman intern downloading (libalpm) obsolete. b) Downloads for *all** packages(incl. database files) must be handled with wget or curl, which produces verbose or zero output which breaks our normal pacman output. c) The verifying part should not be delegated to the user. Ideally pacman would handle this process itself. (I'm nor a c programmer). #Q: Must we real use gpg command line? Must we use gpg? My experience with other Trust-Solutions are low. Also it seems that there are no good libraries to gpg for accessing functions from c programs. http://www.gnupg.org/related_software/libraries.en.html Thomas(brain0) mentions for ex. gnutls or openssl If we could integrate gpg (command-line or by lib) better in our framework then i think: gpg is a good, well known solution. #Q: Signing only the database is not secure! Yes, it would currently only secure our package hash/checksum functions against manipulations, not the packages itself. But IMHO it's a good starting point to get forward. Ideally we must sign the db files also when we sometimes have a super dupper package signing framework ;-) So let's start (and gain experience) fist with the db files. Currently our check-sums(md5) are only download check-sums. They could be manipulate (and therefor easily the corresponding package) on each station after the db leaves gerolde. From a secure view the checksums are useless. If we sign our db file we secure the checksums against manipulating. Not the packages itself. But package manipulating is a lot more difficult to do as in our current situation. And we could switch to a better package check summing solution than md5sum to gain more secure against package manipulation. Ideally we come some day to a framework were also the packages are signed by packagers/developers. Some days. Next step. That are my thoughts on this thing. Surely not complete. (Sorry for my not good English ;-) I attach also a tar archive with a) a repo-add patch and b) a download script for using in pacman.conf) Regards Gerhard

1 0