- Pacman-dev - lists.archlinux.org

[pacman-dev] Patch: Clean up API
by Kerrick Staley 01 Jun '11

01 Jun '11

All, This patch fixes API inconsistencies: A) All references to PGP were removed within names, because such reference is unnecessary. All references to GnuPG's home directory were changed to 'gpgdir' (as opposed to e.g. 'signaturedir'), because this directory is specific to GnuPG. B) makepkg and repo-add now use -S/--sign for signing packages. I didn't find an issue with --nosign and --key. C) Config file directives were not changed because they make enough sense as-is. Unlike functions and flags, you don't have to memorize directives, because they are already given in the config file when you edit it. D) A bug was fixed: repo-add previously used the user's GPG directory when verifying the signature on an old database. It now uses pacman's directory for this purpose. I added a flag --gpgdir to allow configuration of this directory. The patch conflicts with Pang Yan Han's patches. Yan Han, could you please merge the two patch sets? Can the patch be reviewed quickly and either accepted or rejected with suggestions for correction? I realize it should be broken into smaller patches, but I'm inexperienced with git, and I didn't want to wait until tomorrow to submit the changes. The patch is signed-off by: Kerrick Staley <mail(a)kerrickstaley.com> -Kerrick Staley

4 4

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

01 Jun '11

> Hello Kerrick, > > As you say, pacman is not a system, just lines of code, it provides > tools to use gpg as a security system, and any system discussions go > to arch-general(a)archlinux.org. Few Archlinux developers, as far as I > know, read the pacman-dev mailing-list. > > Rémy. > Rémy, OK, I suppose I am wrong. Understood. -Kerrick Staley

1 0

[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

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.5.2-15-gf2c4e7e
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, maint has been updated via f2c4e7e55220addef0581d1c38cc7363b5a0884c (commit) via ba467779bb0faa6ea81d91759c2224592091bbe3 (commit) via aec60e37822509a1ca7fc53244878d3f1505d964 (commit) via 93f02f5793ad7907aa0bc7c4a9fe64f0c7ce86f6 (commit) via 3000b6b473422dca3670c922c24d0e15e963281a (commit) via ac6f6b317ae4bb7adf5ea08fbad6a75f024ff75a (commit) via b9a2318becfc9d6ffb92e602adf433faa8cec383 (commit) from b14c5477e5e4483352d304a1e97de5922948b934 (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 f2c4e7e55220addef0581d1c38cc7363b5a0884c Author: Dan McGee <dan(a)archlinux.org> Date: Thu May 19 16:59:53 2011 -0500 Coding style cleanups; add a null check Signed-off-by: Dan McGee <dan(a)archlinux.org> commit ba467779bb0faa6ea81d91759c2224592091bbe3 Author: Dan McGee <dan(a)archlinux.org> Date: Mon May 16 11:52:49 2011 -0500 Ensure --print doesn't enable --noconfirm when not expected This is at best a hack around the way we currently do our --print magic, but at least prevents someone from shooting themselves in the foot as indicated in FS#24287. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit aec60e37822509a1ca7fc53244878d3f1505d964 Author: Dan McGee <dan(a)archlinux.org> Date: Mon May 16 11:50:13 2011 -0500 Fix segfault when uninstalling broken backed-up symlink Issue FS#24230. If a symlink is broken and included in the removal process of a package, we blew up and segfaulted due to alpm_compute_md5sum() returning NULL and then performing a strcmp() operation. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 93f02f5793ad7907aa0bc7c4a9fe64f0c7ce86f6 Author: Dan McGee <dan(a)archlinux.org> Date: Mon May 16 11:32:33 2011 -0500 Add test for FS#24230, dead backup symlink removal This currently causes a segfault, which is bad news. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 3000b6b473422dca3670c922c24d0e15e963281a Author: Dan McGee <dan(a)archlinux.org> Date: Mon May 16 11:08:32 2011 -0500 pactest: treat symlinks with more respect Don't call os.stat() when we should be using os.lstat(); this allows us to actually test dead symlinks that don't have a corresponding file. Add a new LINK_EXIST rule that complements FILE_EXIST for a similar purpose. Signed-off-by: Dan McGee <dan(a)archlinux.org> commit ac6f6b317ae4bb7adf5ea08fbad6a75f024ff75a Author: Dan McGee <dan(a)archlinux.org> Date: Mon May 16 10:19:21 2011 -0500 Transifex updates Signed-off-by: Dan McGee <dan(a)archlinux.org> commit b9a2318becfc9d6ffb92e602adf433faa8cec383 Author: Dave Reisner <d(a)falconindy.com> Date: Sat May 14 12:54:03 2011 -0400 trans.c: create transaction prior to checking DB version The addition of the DB version check introduces a lag time between the lockfile creation and the transaction initialization. In cases where the local DB is large enough and/or the user's disk is slow enough, this time is significant enough that its possible for a user to send a SIGINT and leave behind a db.lck file. Signed-off-by: Dave Reisner <d(a)falconindy.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- 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 | 12 +++++++--- test/pacman/pmpkg.py | 2 +- test/pacman/pmrule.py | 8 +++++++ test/pacman/tests/symlink002.py | 43 +++++++++++++++++++++++++++++++++++++++ test/pacman/util.py | 6 +--- 9 files changed, 84 insertions(+), 28 deletions(-) create mode 100644 test/pacman/tests/symlink002.py hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] Package signing in pacman
by Dark Byte 17 May '11

17 May '11

Hello dear pacman developer mailing list readers. Right now my favourite distribution for a lot of cases would be Arch, but i have concerns about security as there (right now) is no package signing mechanism established in pacman. I've been asking in the #archlinux IRC channel and goit pointed here. Could someone give me any further information about the ongoing process of implementing package signing mechanism in pacman? Thanks a lot. Yours sincerely, - Armin

4 3

[pacman-dev] [PATCH] Ensure --print doesn't enable --noconfirm when not expected
by Dan McGee 16 May '11

16 May '11

This is at best a hack around the way we currently do our --print magic, but at least prevents someone from shooting themselves in the foot as indicated in FS#24287. Signed-off-by: Dan McGee <dan(a)archlinux.org> --- src/pacman/pacman.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index 0ad0354..8bdb216 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -1416,7 +1416,7 @@ int main(int argc, char *argv[]) } /* set up the print operations */ - if(config->print) { + if(config->print && !config->op_s_clean) { config->noconfirm = 1; config->flags |= PM_TRANS_FLAG_NOCONFLICTS; config->flags |= PM_TRANS_FLAG_NOLOCK; -- 1.7.5.1

1 0