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

[pacman-dev] Examples in the manpages
by Nico Schottelius 04 Oct '11

04 Oct '11

Dear pacman-devs, after a funny replace pacman-with-pacman-git evening, I digged around a bit into makepkg and pacman and noticed there are no examples in the manpages. Is that intented or would you like to/accept patches which add the EXAMPLES section? Cheers, Nico -- New PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 Please resign, if you signed 9885188C or 8D0E27A4. Currently moving *.schottelius.org to http://www.nico.schottelius.org/ ...

13 47

[pacman-dev] Status of sodeps?
by Florian Pritz 09 Jun '11

09 Jun '11

It's been quite a while since I last brought this up so what's the current status? Older discussions and the link to my repo are here [1]. [1] https://wiki.archlinux.org/index.php/Pacman_Roadmap#sodepends -- Florian Pritz -- {flo,bluewind}(a)server-speed.net

5 11

[pacman-dev] [PATCH 0/6] Package signing patches
by Pang Yan Han 09 Jun '11

09 Jun '11

This is a series of patches which can hopefully take package signing a small step forward. Patch 1/6 lets pacman -v print the GPG Dir Patch 2/6 updates the pacman manpage's --gpgdir section and adds a commented GPGDir option in pacman.conf which shows the user the default gpgdir. Patch 3/6 updates Makefile.am to create the default gpgdir, pubring.gpg and trustdb.gpg if they do not exist. Patch 4/6 adds a --verify option to pacman which lets the user control the level of signature verification. Valid arguments to --verify include "always", "optional", "never". Think of this as a way to override the "VerifySig" option in pacman.conf . In addition Patch 4/6 updates configure.ac to output gpgdir at the end of ./configure. Patch 5/6 updates the help text of pacman-key with regards to --gpgdir. Patch 6/6 adds a --import-trustdb option to pacman-key. This allows the user to import a selected trustdb upon confirmation. For Patch 6/6, Bash is not really my strong point and I took quite some time to get it right. Please help me check it. Thanks! Pang Yan Han (6): Let pacman -v print GPG Dir Update pacman manpage and pacman.conf for gpgdir Update Makefile.am and configure.ac for gpgdir Add --verify option for signature level pacman-key: print default gpgdir in usage pacman-key: add --import-trustdb option Makefile.am | 7 +++- configure.ac | 1 + doc/pacman-key.8.txt | 4 ++ doc/pacman.8.txt | 16 ++++++--- etc/pacman.conf.in | 1 + scripts/pacman-key.sh.in | 83 +++++++++++++++++++++++++++++++++++++++++++++- src/pacman/conf.h | 3 +- src/pacman/pacman.c | 16 +++++++++ 8 files changed, 122 insertions(+), 9 deletions(-) -- 1.7.5.rc0.101.g3d23c

6 24

[pacman-dev] Finishing off the package signing issue -- Update
by Kerrick Staley 01 Jun '11

01 Jun '11

All, I examined the code in pacman's git master branch, and I found that it appears nearly finished. There are some issues, both blocking and non-blocking. Note that the following statements are to be interpreted as suggestions and may be revised if anyone has objections; if there are no objections, then this is the course of action that should be taken. Blocking: 1) The option/function naming conventions need to be unified, per https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . This will be significantly harder to fix once the signing feature is shipped. 2) A means of initially installing keys and of updating the list of keys must be created. This will be implemented as a package called pacman-keys. [1] 3) The Arch Developers must create keys. The page https://wiki.archlinux.org/index.php/DeveloperWiki:Signing_Packages must be finalized, and then an informational email can be posted to arch-general. 4) The Arch Developers must place their keys into the pacman-keys package. The developers that can access the central repository can update the package directly. The developers that lack this access (if any) can generate a fingerprint, email their key to a developer with access, and use Skype to verify the fingerprint. If this is a problem, other arrangements can be made. 5) The existing packages and databases on the central repository need to be signed. A single developer can do this. 6) The entire signing process needs to be tested, and pactest tests should be written for it. 7) The pacman manpage should be reviewed and finalized. Non-blocking: 1) Package validation without root privileges must be implemented. Fixing this issue after the signing feature is introduced will not require more work than fixing it first. Omission of this feature will not decrease security but will cause inconvenience. 2) pacman-key should be made production-ready. pacman-key is nonessential because users will typically not edit pacman's trustdb, and pacman-key's functionality is available via sudo GNUPGHOME=/etc/pacman.d/gnupg gpg --options although this usage is cumbersome since it is not tailored for pacman usage. pacman-key should be renamed to pacman-manage-keys to avoid confusion with the pacman-keys package. 3) The documentation for developer tools (makepkg, repo-add) should be reviewed and finalized. 3) The page http://www.archlinux.org/download/ needs to be made to use HTTPS. This can be done independently of package signing implementation, but is necessary for complete security. 4) The output of tar -cf - /etc/pacman.d/gnupg/pacman_{valid,revoked}_keys | sha256sum as executed on an up-to-date system should be posted on an HTTPS page somewhere on archlinux.org and updated upon updates to the pacman-keys package. 5) Further issues are given at https://wiki.archlinux.org/index.php/User:Allan/Package_Signing . I have not had a chance to investigate these issues, but they appear to be non-blocking. Questions: 1) I am unsure as to who has access to the central repository regarding blocking issue 4, so if someone could clarify, I would appreciate it. 2) pacman-key should be updated after pacman but before any other packages. I am not sure if the SyncFirst field in /etc/pacman.conf supports this behavior. If not, the two packages will be both placed in this field and will be designed to install properly in either order until the SyncFirst functionality can be improved. 3) I don't know how quickly validated signatures from every single developer can be gathered, so maybe this will be an issue; I'm not sure. 4) I haven't yet had a chance to see how the documentation is, but pacman's manpage should be reviewed before shipping; manpages for developer-side tools can be reviewed after shipping. 5) I'm not sure what "output when downloading signature file - name when downloaded" from https://wiki.archlinux.org/index.php/User:Allan/Package_Signing means. I think it means that there is no indication when a database signature is being downloaded. I realize this message was rather long and does not have any patches attached to it. I apologize, but I felt that these basic points should be straightened out as development work continues. Tomorrow, I will transcribe some of the information in this email to https://wiki.archlinux.org/index.php?title=Pacman_package_signing, with expanded information on outstanding issues. If you are interested, please adopt an issue and also inform others so that work is not duplicated. If you have information that may be useful to others working on package signing, please place it on this page. I am working on blocking issue 1 and will be done fairly soon. I will then start to work on 2 and 3. 6 and 7 are big issues, so if anyone wants to help out, that'd be a good place. 4 and 5 require action of the Arch Developers; I only list them for completion. [1] This package will place keys (as generated by gpg --export) into the /etc/pacman.d/gnupg/pacman_valid_keys and /etc/pacman.d/gnupg/pacman_revoked_keys directories. The .INSTALL file will update the /etc/pacman.d/gnupg/trustdb.gpg according to the directories' contents. The PKGBUILD for this package will download valid and revoked keys from an HTTPS page on archlinux.org. Before the package is updated, the HTTPS page will be updated, so that the package will contain the changes when built on the developer's machine. The PKGBUILD cannot just copy keys out of the trustdb (with a special option to add or revoke keys for developers) because the PKGBUILD should be able to make the package even when the package isn't already properly installed. Or maybe it can just copy them; I'm too tired right now to decide which is best. Carpe Noctem, Kerrick Staley

5 9

[pacman-dev] [PATCH 4/6] Add --verify option for signature level
by Pang Yan Han 01 Jun '11

01 Jun '11

The --verify option allows the user to change pacman's default signature verification level. It can take in one of "Always", "Optional" or "Verify". Signed-off-by: Pang Yan Han <pangyanhan(a)gmail.com> --- This is a reroll after Remy suggested that it's better to set the signature verification level supplied from the command line in setlibpaths(). A new field is introduced in struct config which stores what the user passes to the --verify option at the command line. Is it possible for us to change option_verifysig to compare to non-caps versions of "Always", "Optional" and "Never"? src/pacman/conf.c | 14 ++++++++++++++ src/pacman/conf.h | 4 +++- src/pacman/pacman.c | 4 ++++ 3 files changed, 21 insertions(+), 1 deletions(-) diff --git a/src/pacman/conf.c b/src/pacman/conf.c index 370ec51..869c005 100644 --- a/src/pacman/conf.c +++ b/src/pacman/conf.c @@ -68,6 +68,7 @@ int config_free(config_t *oldconfig) free(oldconfig->rootdir); free(oldconfig->dbpath); free(oldconfig->logfile); + free(oldconfig->sigverify); free(oldconfig->xfercommand); free(oldconfig->print_format); free(oldconfig); @@ -474,6 +475,19 @@ static int setlibpaths(void) } } + /* Set the signature verification level to what the user requested */ + if(config->sigverify) { + pgp_verify_t verify = option_verifysig(config->sigverify); + if (verify != PM_PGP_VERIFY_UNKNOWN) { + ret = alpm_option_set_default_sigverify(verify); + if(ret != 0) { + pm_printf(PM_LOG_ERROR, _("problem setting sigverify '%s' (%s)\n"), + config->sigverify, alpm_strerrorlast()); + return ret; + } + } + } + /* add a default cachedir if one wasn't specified */ if(alpm_option_get_cachedirs() == NULL) { alpm_option_add_cachedir(CACHEDIR); diff --git a/src/pacman/conf.h b/src/pacman/conf.h index 76c76cf..d08f83c 100644 --- a/src/pacman/conf.h +++ b/src/pacman/conf.h @@ -41,6 +41,7 @@ typedef struct __config_t { char *dbpath; char *logfile; char *gpgdir; + char *sigverify; /* TODO how to handle cachedirs? */ unsigned short op_q_isfile; @@ -111,7 +112,8 @@ enum { OP_ASEXPLICIT, OP_ARCH, OP_PRINTFORMAT, - OP_GPGDIR + OP_GPGDIR, + OP_VERIFY }; /* clean method */ diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index 8458c97..1e58890 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -438,6 +438,9 @@ static int parsearg_global(int opt) config->logfile = strndup(optarg, PATH_MAX); break; case OP_NOCONFIRM: config->noconfirm = 1; break; + case OP_VERIFY: + config->sigverify = strdup(optarg); + break; case 'b': check_optarg(); config->dbpath = strdup(optarg); @@ -635,6 +638,7 @@ static int parseargs(int argc, char *argv[]) {"arch", required_argument, 0, OP_ARCH}, {"print-format", required_argument, 0, OP_PRINTFORMAT}, {"gpgdir", required_argument, 0, OP_GPGDIR}, + {"verify", required_argument, 0, OP_VERIFY}, {0, 0, 0, 0} }; -- 1.7.5.rc0.101.g3d23c

2 1

[pacman-dev] [PATCH] alpm_list: fix typo in doxygen comment
by Pang Yan Han 24 May '11

24 May '11

Signed-off-by: Pang Yan Han <pangyanhan(a)gmail.com> --- lib/libalpm/alpm_list.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/libalpm/alpm_list.c b/lib/libalpm/alpm_list.c index d2e0947..c2b30ad 100644 --- a/lib/libalpm/alpm_list.c +++ b/lib/libalpm/alpm_list.c @@ -286,7 +286,7 @@ alpm_list_t SYMEXPORT *alpm_list_msort(alpm_list_t *list, size_t n, alpm_list_fn /** * @brief Remove an item from the list. - * item is not freed; this is the responsiblity of the caller. + * item is not freed; this is the responsibility of the caller. * * @param haystack the list to remove the item from * @param item the item to remove from the list -- 1.7.5.rc0.101.g3d23c

2 1

[pacman-dev] Finishing off the package signing issue -- call for contributors
by Kerrick Staley 23 May '11

23 May '11

Hello, I'm new to this mailing list, but my name's Kerrick Staley. I'm fairly new to the Arch community: I've used Arch for 2.5 years now. I would like to spearhead an effort to finish the implementation of signed packages in Arch that Allan has gone to the effort to start. I've only been working on the issue for about 4 days now and don't have much to show yet, but I'm sending this message out to stop the bickering as well as to query for interested developers who would be willing to help me (no background knowledge required, just strong coding skills, patience, and dedication). Please reply to this message if you are interested. It seems there are a lot of users who would like this feature and can contribute, but are prevented by a lack of documentation and technical knowledge, so I will create plenty of documentation regarding the issue and what needs doing. I should warn that I'm a rather inexperienced programmer in the broad scale of things and am unfamiliar with pacman's source code, so I ask that developers on the pacman-dev mailing list have extra patience when I ask questions. I'm sure that even just the cessation of angry signing-related inquiries to this list will be reward enough for your help as I implement this feature. I would like this feature to be in active use in 3 months, 2 if possible. Since a working system will require cooperation and understanding from all developers, the human aspects of this project may prove more difficult than the actual coding, therefore ***I ask that all Developers and Trusted Users stay tuned to this list and read future information I will give regarding system configuration and key management.*** I might be busy this weekend, but I should have some things started within a couple of days. Thanks, Kerrick Staley

6 13

Re: [pacman-dev] About pacman and libalpm workflow
by Rémy Oudompheng 21 May '11

21 May '11

On 2011/5/21 ari edelkind <edelkind+arch-pacman(a)gmail.com> wrote: > - What's the general idea -- the program flow -- of the way it's > currently being implemented? Pseudo-code would be perfect for > answering this, but really, anything with system-level details > will do (the "package signing proposal" is not current and does > not contain system-level details). Hello Ari, It's a bit difficult to answer that question, I don't exactly what documentation sources there are out there. I'll try a rough draft, and then you can ask more questions if you want. Also try to have a look at pyalpm: it contains example scripts in Python that try to replicate pacman 3.5 behaviour. Here is how to use libalpm : - initialize it (alpm_initialize) - set options (alpm_option_set_*) - register databases (alpm_db_register_sync) - do something (many functions there) - unregister databases - release the library (alpm_release) In the "do something" part, you may perform a transaction, that is, installation or uninstallation of packages. Transactions are done as follows : - alpm_trans_init with proper options - alpm_trans_add / alpm_trans_remove (says which packages you want to add or remove) - alpm_trans_prepare : this will resolve dependencies and conflicts - alpm_trans_commit : this will download packages, check them (md5 or signature), and install/remove them - alpm_trans_release() The functions that are called to check signature are alpm_db_check_pgp_signature, alpm_pkg_check_pgp_signature. Options make this check optional if needed. Rémy.

3 3

[pacman-dev] Package signing in pacman
by ari edelkind 21 May '11

21 May '11

yaro at marupa wrote: > It's under development. To be honest a lot of Arch users are tired of > this discussion popping up. If you want it to show up sooner, then you > could help by submitting patches of your own to the pacman developers. > > It'll get here when it gets here. This is a poor attitude. A better attitude would be, "Here's how you can help: ..." "... Submitting patches of your own" is an invalid continuation of that response. Patches? For what? Where's the documentation of the way it should function? Where's the documentation of the current infrastructure? Where's the specific information about what's left to do? Is the information recent? This page: https://wiki.archlinux.org/index.php/Package_Signing_Proposal_for_Pacman ... is a "proposal". It was last edited a year ago. It does not help. This page: https://bugs.archlinux.org/task/5331 ... is a "task" ticket, in the tracker, but it doesn't offer much in the way of relevant information. It does not help. This page: https://wiki.archlinux.org/index.php/User:Allan/Package_Signing ... was updated within the past month, at least, but is, as far as i can tell, a brain dump for Allan himself. Information is sparse, implementation details are almost nonexistent, and TODO items are vague. It does not help. In 2010, based on information present in the above-referenced tracker ticket, i tried contacting the Arch developers who appeared to be involved, offering to contribute, and got no response. Allan's Package_Signing page didn't exist yet. As far as i can tell, at this point, that ticket is even assigned to the wrong person. You can't make it difficult for people to contribute and then complain that you aren't receiving contributions. I'm not downplaying the effort that Allan (et al.?) has put forth -- i think it's excellent! But so far, this has all the markings of a single-person project, being coded by someone who doesn't _want_ contributions. Typically, here's what people who do want contributions supply: - an overview of the program internals and general API - details about how the current project _should_ function. - API notes on what has been implemented for the current project thus far. - DETAILS on what portions of the project remain, so that others can pick them up. I can do without the overview of program internals. The latter three are rather more important. So, why not adopt a better attitude -- indeed, perhaps a better method -- and actually try to get contributors? In case it still isn't clear: I'd love to help. I'd love to write patches. I'd love to submit them. I'd love to see pacman package signing in operation, so much so that i'm willing to devote some of my scant time to do so. Now, somebody (Allan?), please make it reasonable for me, and others like me, to even try. Thanks, ari

3 5

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.5.2-185-g11fb9c7
by dan＠archlinux.org 19 May '11

19 May '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 11fb9c767450dc193bbeef755c228aa620df75d9 (commit) via f2c4e7e55220addef0581d1c38cc7363b5a0884c (commit) via ba467779bb0faa6ea81d91759c2224592091bbe3 (commit) via aec60e37822509a1ca7fc53244878d3f1505d964 (commit) via 93f02f5793ad7907aa0bc7c4a9fe64f0c7ce86f6 (commit) via 3000b6b473422dca3670c922c24d0e15e963281a (commit) via ac6f6b317ae4bb7adf5ea08fbad6a75f024ff75a (commit) via b9a2318becfc9d6ffb92e602adf433faa8cec383 (commit) from 70cf4546d6d35ef9ef2751f37853cde679c88aa7 (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 11fb9c767450dc193bbeef755c228aa620df75d9 Merge: 70cf454 f2c4e7e Author: Dan McGee <dan(a)archlinux.org> Date: Thu May 19 17:17:32 2011 -0500 Merge branch 'maint' Conflicts: lib/libalpm/trans.c src/pacman/query.c ----------------------------------------------------------------------- Summary of changes: lib/libalpm/remove.c | 2 +- lib/libalpm/trans.c | 19 +++++++++-------- po/fi.po | 15 +++++++------ src/pacman/pacman.c | 5 ++- src/pacman/query.c | 4 +++ test/pacman/pmpkg.py | 2 +- test/pacman/pmrule.py | 8 +++++++ test/pacman/tests/symlink002.py | 43 +++++++++++++++++++++++++++++++++++++++ test/pacman/util.py | 6 +--- 9 files changed, 80 insertions(+), 24 deletions(-) create mode 100644 test/pacman/tests/symlink002.py hooks/post-receive -- The official pacman repository

1 0