I like the idea of GPG signed repositories, but they are just about useless if they are signing MD5s. MD5 is very insecure, but good for normal file integrity checking. Can Pacman use SHA-256 or similiar? Another thing to watch out for is malicious publication of old repositories with old and vulnerable packages that have the force option set. I've thought briefly on how to circumvent this, but not enough to have a method I would purpose. Thanks, Teran On Mon, Dec 8, 2008 at 12:34, Dan McGee wrote:

On Mon, Dec 8, 2008 at 4:55 AM, Gerhard Brauer wrote:

...

Am Sun, 7 Dec 2008 15:18:32 -0600 schrieb "Dan McGee" :

...

I did quite a bit more work with GPG today. I wrapped my head around GPGME, which presents a nice C interface to the GPG stuff so we are now a lot closer to a working implementation: http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=shortlog;h=refs/heads/ne...

...

From the script side of things, I didn't change much. The libalpm code has changed considerably, and there is still a lot of room for improvement. Let me know if you guys have questions.

With heads/newgpg pacman doesn't check or find the .sig Files. If starting with --debug i got these debug messages:

debug: md5(/var/cache/pacman/pkg/abook-0.5.6-3-i686.pkg.tar.gz) =79777684f62164 934a1264df66b8fdc6 debug: returning error 35 from gpgme_init : signature directory not configured correctly debug: installing packages debug: found cached pkg: /var/cache/pacman/pkg/abook-0.5.6-3-i686.pkg.tar.gz debug: loading target '/var/cache/pacman/pkg/abook-0.5.6-3-i686.pkg.tar.gz' debug: no package signature file found

Where or what have i to configure as the "gpgme_init : signature directory"? My public key is in /root/.gnupg/pubring.gpg. I tried it also with /tmp/testing.gpg but the same error. AFAI could read the code this may belongs to commit: http://code.toofishes.net/gitweb.cgi?p=pacman.git;a=commit;h=1a286336147c7d3... I see a prog gpgme-config, but don't see what i could do with ;-)

Help ;-)

I didn't promise this worked out of the box- I just meant that it was a better start than the other code. You're either going to have to know C and understand what is going on (and fix it), or wait for it to be in a better state of completion.

-Dan _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

On Mon, Dec 08, 2008 at 07:08:20AM -0600, Dan McGee wrote:

We sign *packages*, not repositories. Will this damn thing about MD5 please die? "Fixing" that still fixes nothing, and I'll pay one million USD to someone that can actually forge a package with a given MD5.

Hah hah! I have my work ahead of me!

Aaron Griffin schrieb:

Forcing md5sum collisions requires arbitrary null padding. tar can (I think) support this, but not if it's compressed. You can't arbitrarily put nulls in the middle of a gzip'd stream...

You can put arbitrary data at the end of a gzip archive. This has been used here: http://web.archive.org/web/20011212144451/fatphil.org/maths/illegal1.html

Am Mon, 8 Dec 2008 06:34:06 -0600 schrieb "Dan McGee" : Hi Dan, Hi Developers!

I didn't promise this worked out of the box- I just meant that it was a better start than the other code. You're either going to have to know C and understand what is going on (and fix it), or wait for it to be in a better state of completion.

I know i make myself very unpopulary with this... Anything new which could be tested? As far as i see we have a very good start shortly after the discussion about "signing". Now a stagnation. I'm aware that the pacman developers are also short in time. Should maybe the git head from Dan's repo (newgpg) posted on arch public-devel or arch-general so that C programmer could have look? Or what is with the idea to start first with package database signing? If package signing is hard to implement maybe we shouldn't make the second step before the first.

-Dan

Regards Gerhard

There are a few people like myself who are interested in working on pacman. I started looking at pacman code a few weeks back, had a look at bug tracker and send a patch for a simple feature(pacman -Qo which). After that i was stuck because i couldnt find anything to work on. Most of the feature requests are huge changes and it doesnt seem that there is consent on those even within current developers. So it would be better if we can have a roadmap sort of thing for pacman ( not the TODO.dan and TODO.aaron in source) with features which developers want to include but are unable because of lack of time. Basically something which beginners can use to get their hand wet......... (If such a list already exists, i couldnt find it) Thanks On Sat, Dec 13, 2008 at 7:48 PM, Dan McGee wrote:

Simple fact- there is no one that is both interested AND can program in C.

If I attached a $500 bounty, we might get results. Until then, we just don't have enough people in the community actually interested in working on pacman- just those that ask for new features. This code has been posted on every single mailing list, every developer has seen it, etc. and yet we still have no one else working on it. I can't quit my day job.

-Dan _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev

On Mon, Dec 15, 2008 at 7:11 AM, Allan McRae wrote:

Jatheendra wrote:

...

There are a few people like myself who are interested in working on pacman. I started looking at pacman code a few weeks back, had a look at bug tracker and send a patch for a simple feature(pacman -Qo which). After that i was stuck because i couldnt find anything to work on. Most of the feature requests are huge changes and it doesnt seem that there is consent on those even within current developers. So it would be better if we can have a roadmap sort of thing for pacman ( not the TODO.dan and TODO.aaron in source) with features which developers want to include but are unable because of lack of time. Basically something which beginners can use to get their hand wet.........

(If such a list already exists, i couldnt find it)

Thanks

Hi,

This is something I have not got around to finishing which should be fairly simple to do:

FS#9424 - db.lck storing pid I have a patch which stores the pid in the lock file here: http://dev.archlinux.org/~allan/gitweb/gitweb.cgi?p=pacman.git;a=commitdiff;... The idea is that when a lock file is present, pacman reads in this number, checks if the process exists and if not automatically removes the lock file.

Other than that, look at bugs in the low or very low priority categories. Most ideas we have for pacman improvement are posted there so we don't lose them. The lower priority level normally mean that it is a nice idea but the devs have other things they want to do. I found these to be a goldmine of fairly simple fixes when I was learning the pacman code base. If you have queries about a specific idea, just post here asking for opinions or some direction on how to fix it.

A few ideas: * globbing for sync operations: http://bugs.archlinux.org/task/1561 * multiple pacman instances on same cache: http://bugs.archlinux.org/task/8226 * Allow -Qo to perform functional which (started, looks like it still needs some follow-up): http://bugs.archlinux.org/task/8798