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.

On 19/02/11 09:40, IgnorantGuru wrote:
<snip>

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.


Everything up until this point is not related to pacman development at
all and should be taken up with whoever provides the repos you use.
Pacman is not Arch Linux specific...


Note that the current implementation does not preclude having the
signatures alongside packages in the repos. It just uses the version
provided in the repo database. Also, if you use "pacman -U <url>"
pacman will try downloading any signature alongside the package, so it
is more than likely the signatures will end up there.


<snip>


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.


We are using gpgme which is maintained by gpg developers. So we are not
reinventing any wheel. If that is an ill-maintained and contains
security issues, then why trust gpg at all?



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.


Have you actually looked at the current implementation at all? I'm not
sure how much simpler it could get. The package is downloaded and its
signature - either in the repo or detached - is checked using gpg via
gpgme. There is a way to disable signature check and select which
keyring is being used. And that is about it...



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.


Umm... no... the *pacman* devs just feel the have better things to do
with their lives, including things of higher interest to develop in
pacman. Also, (almost) no-one who considers this super-critical to
implement has done anything about it. And those that have obviously
have not (yet?) seen it through to the finish.



In the end, the only way anything will get implemented is if patches are
provided. (That includes the suggestion of providing signatures in
repos on Arch Linux - look at that devtools/db-scripts projects). Dan
and I have also mentioned our consulting rates in the past, which may or
may not increase motivation to finish this...


Finally, *succinct* reports on where the current implementation in
pacman can be improved are also appreciated. But that requires actually
paying attention to what has already been done.


Allan


Sat Feb 19 02:30:01 2011
Return-path: <pacman-dev-bounces@archlinux.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Sat, 19 Feb 2011 02:20:37 +0200
Received: from gerolde.archlinux.org ([66.211.214.132]:44159 helo=archlinux.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <pacman-dev-bounces@archlinux.org>)
id 1PqaYv-0005tG-BL
for tom@linux-archive.org; Sat, 19 Feb 2011 02:20:37 +0200
Received: from gudrun.archlinux.org (gudrun.archlinux.org [66.211.214.131])
by archlinux.org (Postfix) with ESMTP id 138F990156;
Fri, 18 Feb 2011 20:30:28 -0500 (EST)
Received: from archlinux.org (gerolde.archlinux.org [66.211.214.132])
by gudrun.archlinux.org (Postfix) with ESMTP id 6EC00D0017
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 20:30:26 -0500 (EST)
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.161.172 is
authorized to use 'denisfalqueto@gmail.com' in 'mfrom' identity (mechanism
'ip4:209.85.128.0/17' matched)) receiver=gerolde.archlinux.org;
identity=mailfrom; envelope-from="denisfalqueto@gmail.com";
helo=mail-gx0-f172.google.com; client-ip=209.85.161.172
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com
[209.85.161.172])
by archlinux.org (Postfix) with ESMTPS id 35C9890155
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 20:30:25 -0500 (EST)
Received: by gxk5 with SMTP id 5so535gxk.3
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 17:30:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:from:to:subject:date:message-id:x-mailer
:mime-version:content-type:content-transfer-encoding;
bh=Fo+uaKFzJK6bf4maekawzGUgNIauLx+1Td7z4H/GBQA=;
b=wMWO7R/Hq7nmXVekjSe9RtY9JbgtcFUVqJUUdFQFKLqbB41GoGhSrf0nS gHdGWCafk
E5VhI2SqNxhUTrc58jhnX7hBZ+TPio53rswrrkYCI+zbbmY4N6 Kz6OhXwa0iHRFVtF8E
s/n9kfAMsjdZHP65EH3YKrNkRx5kpA6L0kHkc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=from:to:subject:date:message-id:x-mailer:mime-version:content-type
:content-transfer-encoding;
b=bV/q/S2sIkGRQyqpWo++1omrZIX1NJD/DLOg0klTkj7jTj7bvv6qxUdEr0R9KY02fx
uc7HsflWpSFBSquowZNQtZMVXhs5pSgiq9wh01CCUqsmj2BIFz cSoaCuB0SF4Bkgz34M
+Q8FX9LEZrs67Nd9XjlicS/Mhtv29bYDkwKqU=
Received: by 10.151.143.6 with SMTP id v6mr1855106ybn.230.1298079039610;
Fri, 18 Feb 2011 17:30:39 -0800 (PST)
Received: from localhost ([201.80.187.151])
by mx.google.com with ESMTPS id l2sm1327973ybn.15.2011.02.18.17.30.34
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 18 Feb 2011 17:30:38 -0800 (PST)
From: =?UTF-8?q?Denis=20A=2E=20Alto=C3=A9=20Falqueto?=
<denisfalqueto@gmail.com>
To: pacman-dev@archlinux.org
Date: Fri, 18 Feb 2011 23:30:20 -0200
Message-Id: <1298079023-28529-1-git-send-email-denisfalqueto@gmail.com>
X-Mailer: git-send-email 1.7.4.1
MIME-Version: 1.0
Subject: [pacman-dev] [package signing] Some new patches
X-BeenThere: pacman-dev@archlinux.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: Discussion list for pacman development <pacman-dev@archlinux.org>
List-Id: Discussion list for pacman development <pacman-dev.archlinux.org>
List-Unsubscribe: <http://mailman.archlinux.org/mailman/options/pacman-dev>,
<mailtoacman-dev-request@archlinux.org?subject=unsubscribe>
List-Archive: <http://mailman.archlinux.org/pipermail/pacman-dev>
List-Post: <mailtoacman-dev@archlinux.org>
List-Help: <mailtoacman-dev-request@archlinux.org?subject=help>
List-Subscribe: <http://mailman.archlinux.org/mailman/listinfo/pacman-dev>,
<mailtoacman-dev-request@archlinux.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pacman-dev-bounces@archlinux.org
Sender: pacman-dev-bounces@archlinux.org

Hi,

These pathces are kind of sitting here in my drive. So
I would like to send it, so we can discuss them.

They are named after some items in the TODO list for
package signing:


https://wiki.archlinux.org/index.php/User:Allan/Package_Signing


Just a little fix to make it the way other pacman related
scripts are doing.



This is a merge of the two first TODO items for makepkg. They are very
interdependent, so one patch is better than two, IMHO.


When I was implementing the changes in makepkg, I discovered a little problem
with some options handling, so this fixes it. Also implements the first TODO
item for pacman-key.


I have some questions about repo-add, but I'll put it in another email.

So, comments very much appreciated, as always.

--
Denis Falqueto


Sat Feb 19 02:30:01 2011
Return-path: <pacman-dev-bounces@archlinux.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Sat, 19 Feb 2011 02:20:55 +0200
Received: from gerolde.archlinux.org ([66.211.214.132]:44284 helo=archlinux.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <pacman-dev-bounces@archlinux.org>)
id 1PqaZD-0005uF-OQ
for tom@linux-archive.org; Sat, 19 Feb 2011 02:20:55 +0200
Received: from gudrun.archlinux.org (gudrun.archlinux.org [66.211.214.131])
by archlinux.org (Postfix) with ESMTP id 1CD7D90157;
Fri, 18 Feb 2011 20:30:47 -0500 (EST)
Received: from archlinux.org (gerolde.archlinux.org [66.211.214.132])
by gudrun.archlinux.org (Postfix) with ESMTP id 9B3C0D0017
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 20:30:45 -0500 (EST)
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.161.172 is
authorized to use 'denisfalqueto@gmail.com' in 'mfrom' identity (mechanism
'ip4:209.85.128.0/17' matched)) receiver=gerolde.archlinux.org;
identity=mailfrom; envelope-from="denisfalqueto@gmail.com";
helo=mail-gx0-f172.google.com; client-ip=209.85.161.172
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com
[209.85.161.172])
by archlinux.org (Postfix) with ESMTPS id 7B3FD90155
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 20:30:45 -0500 (EST)
Received: by mail-gx0-f172.google.com with SMTP id 5so535gxk.3
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 17:31:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:from:to:cc:subject:date:message-id:x-mailer
:in-reply-to:references:mime-version:content-type
:content-transfer-encoding;
bh=vKgIpFnFuN9eiR4kr8E/yFdT2gZKoo869Uj38miffCM=;
b=tGVSpK3WrG4sIOJJOFddwlXOjd9bCEjEmCNEa4fPNVAwUTCO nFqyoaNsEBQ7sfxyaK
5A0mwQzKp4jihPz2A5udj0cN6Z/dwHA4mRZI1sUXGkvNM9RqIm8x6f7tVhMhtGiHfYc/
2rb2OSq+CaUa8KzL2Z5TBB5M2cCu5hM43F/a0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references
:mime-version:content-type:content-transfer-encoding;
b=Ntr5Kl2FuxgbZ6RB97D/AbOGkKeUtfMbR9DR0C/3+72zgEFqKNprRlrNpbf6iIYffI
NUPtqi7HD6hWTiSLfI07q8hqjC7ZR1Fkl31dPaN4ZCizArSNkb OCC70bWdp1LM2kJhIw
KG4tA0ybuZukjEeoJHgIOGDhddodyv6FqgonA=
Received: by 10.150.137.11 with SMTP id k11mr1968060ybd.108.1298079060671;
Fri, 18 Feb 2011 17:31:00 -0800 (PST)
Received: from localhost ([201.80.187.151])
by mx.google.com with ESMTPS id q4sm804487yba.14.2011.02.18.17.30.54
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 18 Feb 2011 17:31:00 -0800 (PST)
From: =?UTF-8?q?Denis=20A=2E=20Alto=C3=A9=20Falqueto?=
<denisfalqueto@gmail.com>
To: pacman-dev@archlinux.org
Date: Fri, 18 Feb 2011 23:30:21 -0200
Message-Id: <1298079023-28529-2-git-send-email-denisfalqueto@gmail.com>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1298079023-28529-1-git-send-email-denisfalqueto@gmail.com>
References: <1298079023-28529-1-git-send-email-denisfalqueto@gmail.com>
MIME-Version: 1.0
Subject: [pacman-dev] [PATCH 1/3] pacman-key: use macro to configure shebang
X-BeenThere: pacman-dev@archlinux.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: Discussion list for pacman development <pacman-dev@archlinux.org>
List-Id: Discussion list for pacman development <pacman-dev.archlinux.org>
List-Unsubscribe: <http://mailman.archlinux.org/mailman/options/pacman-dev>,
<mailtoacman-dev-request@archlinux.org?subject=unsubscribe>
List-Archive: <http://mailman.archlinux.org/pipermail/pacman-dev>
List-Post: <mailtoacman-dev@archlinux.org>
List-Help: <mailtoacman-dev-request@archlinux.org?subject=help>
List-Subscribe: <http://mailman.archlinux.org/mailman/listinfo/pacman-dev>,
<mailtoacman-dev-request@archlinux.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: pacman-dev-bounces@archlinux.org
Sender: pacman-dev-bounces@archlinux.org

TWlub3IgY2hhbmdlIHRvIHVzZSBtYWNybyB0byBzdWJzdGl0dX RlIHRoZSBzaGViYW5nIHdpdGgg
dGhlIGNvcnJlY3QKc2hlbGwgYmluYXJ5LCBhcyBpcyBkb25lIG luIG90aGVyIHNjcmlwdHMuCgpT
aWduZWQtb2ZmLWJ5OiBEZW5pcyBBLiBBbHRvw6kgRmFscXVldG 8gPGRlbmlzZmFscXVldG9AZ21h
aWwuY29tPgotLS0KIHNjcmlwdHMvcGFjbWFuLWtleS5zaC5pbi B8ICAgIDIgKy0KIDEgZmlsZXMg
Y2hhbmdlZCwgMSBpbnNlcnRpb25zKCspLCAxIGRlbGV0aW9ucy gtKQoKZGlmZiAtLWdpdCBhL3Nj
cmlwdHMvcGFjbWFuLWtleS5zaC5pbiBiL3NjcmlwdHMvcGFjbW FuLWtleS5zaC5pbgppbmRleCBi
MmJmYjIzLi5jY2FmNGIyIDEwMDY0NAotLS0gYS9zY3JpcHRzL3 BhY21hbi1rZXkuc2guaW4KKysr
IGIvc2NyaXB0cy9wYWNtYW4ta2V5LnNoLmluCkBAIC0xLDQgKz EsNCBAQAotIyEvYmluL2Jhc2gg
LWUKKyMhQEJBU0hfU0hFTExAIC1lCiAjCiAjICAgcGFjbWFuLW tleSAtIG1hbmFnZXMgcGFjbWFu
J3Mga2V5cmluZwogIyAgICAgICAgICAgICAgICBCYXNlZCBvbi BhcHQta2V5LCBmcm9tIERlYmlh
bgotLSAKMS43LjQuMQoKCg==

Sat Feb 19 02:30:01 2011
Return-path: <pacman-dev-bounces@archlinux.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Sat, 19 Feb 2011 02:21:19 +0200
Received: from gerolde.archlinux.org ([66.211.214.132]:44419 helo=archlinux.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <pacman-dev-bounces@archlinux.org>)
id 1PqaZb-0005w3-QR
for tom@linux-archive.org; Sat, 19 Feb 2011 02:21:19 +0200
Received: from gudrun.archlinux.org (gudrun.archlinux.org [66.211.214.131])
by archlinux.org (Postfix) with ESMTP id 6FE3090161;
Fri, 18 Feb 2011 20:31:11 -0500 (EST)
Received: from archlinux.org (gerolde.archlinux.org [66.211.214.132])
by gudrun.archlinux.org (Postfix) with ESMTP id 03E02D0017
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 20:31:09 -0500 (EST)
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.161.172 is
authorized to use 'denisfalqueto@gmail.com' in 'mfrom' identity (mechanism
'ip4:209.85.128.0/17' matched)) receiver=gerolde.archlinux.org;
identity=mailfrom; envelope-from="denisfalqueto@gmail.com";
helo=mail-gx0-f172.google.com; client-ip=209.85.161.172
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com
[209.85.161.172])
by archlinux.org (Postfix) with ESMTPS id CAE9F90155
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 20:31:08 -0500 (EST)
Received: by mail-gx0-f172.google.com with SMTP id 5so535gxk.3
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 17:31:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:from:to:cc:subject:date:message-id:x-mailer
:in-reply-to:references:mime-version:content-type
:content-transfer-encoding;
bh=vNp78iRZOQsQj25BNsc1vysoGZ82nv0wm5Xl0ZFCqS4=;
b=ijzunm7vv4uh8VXM2scm79nOCPZ97KoSwaAAu3GRbtRM5ctx oRJ4Tnkhm0X7jEzyjM
LtQSwGiFnAlXxmPhHrYN3ux9SbnR4YrC6ZaVrvvFW8iV9N9PWR 4raBrsjgRbgAaCHP71
mGznrTbh9hkga0PtnQ/1V9h4dSqDZuQH6yjvY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references
:mime-version:content-type:content-transfer-encoding;
b=BuTRvJzbhamAWZRkue1YgSxKNPMrgmGj5eppo4q1QRqIyJi4 C/EPYpubAFU+Roi45L
OyW17R7wIsw+V50FdfO/icEqmYObgRlqbrrjxZUO6BrJth+vU/6LcKBJO9Qe7X2enaVz
rGWEOgDn0V+a3Fbg1KA1DSpinIw2o4UjkXZSA=
Received: by 10.236.105.240 with SMTP id k76mr2577973yhg.96.1298079083859;
Fri, 18 Feb 2011 17:31:23 -0800 (PST)
Received: from localhost ([201.80.187.151])
by mx.google.com with ESMTPS id 68sm1752993yhl.19.2011.02.18.17.31.17
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 18 Feb 2011 17:31:23 -0800 (PST)
From: =?UTF-8?q?Denis=20A=2E=20Alto=C3=A9=20Falqueto?=
<denisfalqueto@gmail.com>
To: pacman-dev@archlinux.org
Date: Fri, 18 Feb 2011 23:30:22 -0200
Message-Id: <1298079023-28529-3-git-send-email-denisfalqueto@gmail.com>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1298079023-28529-1-git-send-email-denisfalqueto@gmail.com>
References: <1298079023-28529-1-git-send-email-denisfalqueto@gmail.com>
MIME-Version: 1.0
Subject: [pacman-dev] [PATCH 2/3] makepkg: command line options for signing
packages
X-BeenThere: pacman-dev@archlinux.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: Discussion list for pacman development <pacman-dev@archlinux.org>
List-Id: Discussion list for pacman development <pacman-dev.archlinux.org>
List-Unsubscribe: <http://mailman.archlinux.org/mailman/options/pacman-dev>,
<mailtoacman-dev-request@archlinux.org?subject=unsubscribe>
List-Archive: <http://mailman.archlinux.org/pipermail/pacman-dev>
List-Post: <mailtoacman-dev@archlinux.org>
List-Help: <mailtoacman-dev-request@archlinux.org?subject=help>
List-Subscribe: <http://mailman.archlinux.org/mailman/listinfo/pacman-dev>,
<mailtoacman-dev-request@archlinux.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: pacman-dev-bounces@archlinux.org
Sender: pacman-dev-bounces@archlinux.org

VHdvIG5ldyBjb21tYW5kIGxpbmUgb3B0aW9ucyB3ZXJlIGFkZG VkOgoKLW4sIC0tc2lnbjogZm9y
Y2VzIHRoZSBnZW5lcmF0aW9uIG9mIGEgc2lnbmF0dXJlIGZvcg p0aGUgcmVzdWx0aW5nIHBhY2th
Z2UsIGV2ZW4gaWYgbm90IGNvbmZpZ3VyZWQgaW4gbWFrZXBrZy 5jb25mLgpUaGUgY29tbWFuZCBs
aW5lIGhhcyBwcmVjZWRlbmNlIG92ZXIgdGhlIG9wdGlvbiBpbg ptYWtlcGtnLmNvbmYuIFNvLCBl
dmVuIGlmIG1ha2Vwa2cuY29uZiBoYXMgIXNpZ24gaW4KQlVJTE RFTlYsIHBhc3NpbmcgLS1zaWdu
IHRvIG1ha2Vwa2cgd2lsbCBtYWtlIGl0CnNpZ24gdGhlIHBhY2 thZ2UuCgotLXNpZ253aXRoa2V5
IDxrZXk+OiB0aGVyZSBpcyBhIHBvc3NpYmlsaXR5IG9mIGFub3 RoZXIga2V5CmJlaW5nIHVzZWQs
IGluc3RlYWQgb2YgdGhlIHVzZXIncyBkZWZhdWx0LiBGb3IgZX hlbXBsZSwKcGFjbWFuLWtleXJp
bmcgcGFja2FnZSBjb3VsZCBiZSBzaWduZWQgYnkgYSBtYXN0ZX Iga2V5LApiZWNhdXNlIGl0IG5l
ZWRzIHRvIGJlIHRydXN0ZWQgZXhwbGljaXRseSBieSB0aGUgdX NlcgpiZWZvcmUgdGhlIGluc3Rh
bGxhdGlvbiBvZiB0aGF0IHBhY2thZ2UuIFNvLCB0aGlzIHBhcm FtZXRlcgp3aWxsIGJlIHVzZWQg
dG8gc3VwcGx5IGFuIGlkIGZvciBhIGtleSB0byBiZSB1c2VkIH RvIHNpZ24KdGhlIHBhY2thZ2Uu
CgpTaWduZWQtb2ZmLWJ5OiBEZW5pcyBBLiBBbHRvw6kgRmFscX VldG8gPGRlbmlzZmFscXVldG9A
Z21haWwuY29tPgotLS0KIHNjcmlwdHMvbWFrZXBrZy5zaC5pbi B8ICAgMjggKysrKysrKysrKysr
KysrKysrKysrKystLS0tLQogMSBmaWxlcyBjaGFuZ2VkLCAyMy BpbnNlcnRpb25zKCspLCA1IGRl
bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3NjcmlwdHMvbWFrZX BrZy5zaC5pbiBiL3NjcmlwdHMv
bWFrZXBrZy5zaC5pbgppbmRleCA4MzgxYTc4Li5kYzcxZmZkID EwMDY0NAotLS0gYS9zY3JpcHRz
L21ha2Vwa2cuc2guaW4KKysrIGIvc2NyaXB0cy9tYWtlcGtnLn NoLmluCkBAIC0yOCw3ICsyOCw3
IEBACiAjIG1ha2Vwa2cgdXNlcyBxdWl0ZSBhIGZldyBleHRlcm 5hbCBwcm9ncmFtcyBkdXJpbmcg
aXRzIGV4ZWN1dGlvbi4gWW91CiAjIG5lZWQgdG8gaGF2ZSBhdC BsZWFzdCB0aGUgZm9sbG93aW5n
IGluc3RhbGxlZCBmb3IgbWFrZXBrZyB0byBmdW5jdGlvbjoKIC MgICBhd2ssIGJzZHRhciAobGli
YXJjaGl2ZSksIGJ6aXAyLCBjb3JldXRpbHMsIGZha2Vyb290LC BmaWxlLCBmaW5kIChmaW5kdXRp
bHMpLAotIyAgIGdldHRleHQsIGdyZXAsIGd6aXAsIG9wZW5zc2 wsIHNlZCwgdHB1dCAobmN1cnNl
cyksIHh6CisjICAgZ2V0dGV4dCwgZ3BnLCBncmVwLCBnemlwLC BvcGVuc3NsLCBzZWQsIHRwdXQg
KG5jdXJzZXMpLCB4egogCiAjIGdldHRleHQgaW5pdGlhbGl6YX Rpb24KIGV4cG9ydCBURVhURE9N
QUlOPSdwYWNtYW4nCkBAIC03NCw2ICs3NCw4IEBAIEJVSUxERl VOQz0wCiBDSEVDS0ZVTkM9MAog
UEtHRlVOQz0wCiBTUExJVFBLRz0wCitTSUdOPTAKK1NJR05LRV k9IiIKIFBLR0xJU1Q9KCkKIAog
IyBGb3JjZXMgdGhlIHBrZ3ZlciBvZiB0aGUgY3VycmVudCBQS0 dCVUlMRC4gVXNlZCBieSB0aGUg
ZmFrZXJvb3QgY2FsbApAQCAtMTEwNiw3ICsxMTA4LDcgQEAgY3 JlYXRlX3BhY2thZ2UoKSB7CiB9
CiAKIGNyZWF0ZV9zaWduYXR1cmUoKSB7Ci0JaWYgW1sgJChjaG Vja19idWlsZGVudiBzaWduKSAh
PSAieSIgXV07IHRoZW4KKwlpZiBbWyAkKGNoZWNrX2J1aWxkZW 52IHNpZ24pICE9ICJ5IiAmJiAk
U0lHTiAhPSAxIF1dOyB0aGVuCiAJCXJldHVybgogCWZpCiAJbG 9jYWwgcmV0PTAKQEAgLTExMTYs
NyArMTExOCwxOCBAQCBjcmVhdGVfc2lnbmF0dXJlKCkgewogCQ llcnJvciAiJChnZXR0ZXh0ICJD
YW5ub3QgZmluZCB0aGUgZ3BnIGJpbmFyeSEgSXMgZ251cGcgaW 5zdGFsbGVkPyIpIgogCQlleGl0
IDEgIyAkRV9NSVNTSU5HX1BST0dSQU0KIAlmaQotCWdwZyAtLW RldGFjaC1zaWduIC0tdXNlLWFn
ZW50ICIkZmlsZW5hbWUiIHx8IHJldD0kPworCisJIyBDaGVjay BpZiBTSUdOS0VZIGlzIHZhbGlk
LgorCWxvY2FsIFNJR05XSVRIS0VZPSIiCisJaWYgW1sgIiR7U0 lHTktFWX0iIF1dOyB0aGVuCisJ
CWlmICEgZ3BnIC0tbGlzdC1rZXkgIiR7U0lHTktFWX0iIDE+L2 Rldi9udWxsIDI+JjE7IHRoZW4K
KwkJCWVycm9yICIkKGdldHRleHQgIlRoZSBrZXkgJHtTSUdOS0 VZfSBkb2VzblwndCBleGlzdC4i
KSIKKwkJCWV4aXQgMQorCQlmaQorCQlTSUdOV0lUSEtFWT0iLX UgJHtTSUdOS0VZfSIKKwlmaQor
CSMgVGhlIHNpZ25hdHVyZSB3aWxsIGJlIGdlbmVyYXRlZCBkaX JlY3RseSBpbiBhc2NpaS1mcmll
bmRseSBmb3JtYXQKKwlncGcgLS1kZXRhY2gtc2lnbiAtLXF1aW V0IC0tYmF0Y2ggLS11c2UtYWdl
bnQgJHtTSUdOV0lUSEtFWX0gIiRmaWxlbmFtZSIgMT4vZGV2L2 51bGwgfHwgcmV0PSQ/CiAJaWYg
KCggISByZXQgKSk7IHRoZW4KIAkJbXNnMiAiJChnZXR0ZXh0IC JDcmVhdGVkIHNpZ25hdHVyZSBm
aWxlICVzLiIpIiAiJGZpbGVuYW1lLnNpZyIKIAllbHNlCkBAIC 0xNjE0LDYgKzE2MjcsOSBAQCB1
c2FnZSgpIHsKIAllY2hvICIkKGdldHRleHQgIiAgLS1wa2cgPG xpc3Q+ICAgICBPbmx5IGJ1aWxk
IGxpc3RlZCBwYWNrYWdlcyBmcm9tIGEgc3BsaXQgcGFja2FnZS IpIgogCWVjaG8gIiQoZ2V0dGV4
dCAiICAtLXNraXBpbnRlZyAgICAgIERvIG5vdCBmYWlsIHdoZW 4gaW50ZWdyaXR5IGNoZWNrcyBh
cmUgbWlzc2luZyIpIgogCWVjaG8gIiQoZ2V0dGV4dCAiICAtLX NvdXJjZSAgICAgICAgIEdlbmVy
YXRlIGEgc291cmNlLW9ubHkgdGFyYmFsbCB3aXRob3V0IGRvd2 5sb2FkZWQgc291cmNlcyIpIgor
CWVjaG8gIiQoZ2V0dGV4dCAiICAtbiwgLS1zaWduICAgICAgIF NpZ24gdGhlIHJlc3VsdGluZyBw
YWNrYWdlIHdpdGggZ3BnIikiCisJcHJpbnRmICIkKGdldHRleH QgIiAgLS1zaWdud2l0aGtleSA8
a2V5PlxuXAorICAgICAgICAgICAgICAgICAgIFNlbGVjdHMgYW 4gc3BlY2lmaWMga2V5IHRvIHVz
ZSBmb3Igc2lnbmluZywgaW5zdGVhZCBvZiB1c2VyJ3MgZGVmYX VsdCIpIgogCWVjaG8KIAllY2hv
ICIkKGdldHRleHQgIlRoZXNlIG9wdGlvbnMgY2FuIGJlIHBhc3 NlZCB0byBwYWNtYW46IikiCiAJ
ZWNobwpAQCAtMTY0NSwxMSArMTY2MSwxMSBAQCBmaQogQVJHTE lTVD0oIiRAIikKIAogIyBQYXJz
ZSBDb21tYW5kIExpbmUgT3B0aW9ucy4KLU9QVF9TSE9SVD0iQW NDZGVmRmdoaUxtb3A6clJzViIK
K09QVF9TSE9SVD0iQWNDZGVmRmdoaUxtbm9wOnJSc1YiCiBPUF RfTE9ORz0iYWxsc291cmNlLGFz
cm9vdCxpZ25vcmVhcmNoLGNoZWNrLGNsZWFuLGNsZWFuY2FjaG Usbm9kZXBzIgogT1BUX0xPTkcr
PSIsbm9leHRyYWN0LGZvcmNlLGZvcmNldmVyOixnZW5pbnRlZy xoZWxwLGhvbGR2ZXIiCiBPUFRf
TE9ORys9IixpbnN0YWxsLGxvZyxub2NvbG9yLG5vYnVpbGQsbm 9jaGVjayxwa2c6LHJtZGVwcyIK
LU9QVF9MT05HKz0iLHJlcGFja2FnZSxza2lwaW50ZWcsc291cm NlLHN5bmNkZXBzLHZlcnNpb24s
Y29uZmlnOiIKK09QVF9MT05HKz0iLHJlcGFja2FnZSxzaWduLH NpZ253aXRoa2V5Oixza2lwaW50
ZWcsc291cmNlLHN5bmNkZXBzLHZlcnNpb24sY29uZmlnOiIKIC MgUGFjbWFuIE9wdGlvbnMKIE9Q
VF9MT05HKz0iLG5vY29uZmlybSxub3Byb2dyZXNzYmFyIgogT1 BUX1RFTVA9IiQocGFyc2Vfb3B0
aW9ucyAkT1BUX1NIT1JUICRPUFRfTE9ORyAiJEAiIHx8IGVjaG 8gJ1BBUlNFX09QVElPTlMgRkFJ
TEVEJykiCkBAIC0xNjkzLDYgKzE3MDksOCBAQCB3aGlsZSB0cn VlOyBkbwogCQktUnwtLXJlcGFj
a2FnZSkgICBSRVBLRz0xIDs7CiAJCS0tc2tpcGludGVnKSAgIC AgIFNLSVBJTlRFRz0xIDs7CiAJ
CS0tc291cmNlKSAgICAgICAgIFNPVVJDRU9OTFk9MSA7OworCQ ktLXNpZ24pICAgICAgICAgICBT
SUdOPTEgOzsKKwkJLS1zaWdud2l0aGtleSkgICAgc2hpZnQ7IF NJR05LRVk9JDEgOzsKIAkJLXN8
LS1zeW5jZGVwcykgICAgREVQX0JJTj0xIDs7CiAKIAkJLWh8LS 1oZWxwKSAgICAgICAgdXNhZ2U7
IGV4aXQgMCA7OyAjIEVfT0sKLS0gCjEuNy40LjEKCgo=

Sat Feb 19 02:30:01 2011
Return-path: <pacman-dev-bounces@archlinux.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Sat, 19 Feb 2011 02:21:43 +0200
Received: from gerolde.archlinux.org ([66.211.214.132]:44551 helo=archlinux.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <pacman-dev-bounces@archlinux.org>)
id 1PqaZz-0005xt-Bd
for tom@linux-archive.org; Sat, 19 Feb 2011 02:21:43 +0200
Received: from gudrun.archlinux.org (gudrun.archlinux.org [66.211.214.131])
by archlinux.org (Postfix) with ESMTP id C637190168;
Fri, 18 Feb 2011 20:31:34 -0500 (EST)
Received: from archlinux.org (gerolde.archlinux.org [66.211.214.132])
by gudrun.archlinux.org (Postfix) with ESMTP id 41331D0017
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 20:31:33 -0500 (EST)
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.160.172 is
authorized to use 'denisfalqueto@gmail.com' in 'mfrom' identity (mechanism
'ip4:209.85.128.0/17' matched)) receiver=gerolde.archlinux.org;
identity=mailfrom; envelope-from="denisfalqueto@gmail.com";
helo=mail-gy0-f172.google.com; client-ip=209.85.160.172
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com
[209.85.160.172])
by archlinux.org (Postfix) with ESMTPS id 19B2F90155
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 20:31:32 -0500 (EST)
Received: by gyd12 with SMTP id 12so1974852gyd.3
for <pacman-dev@archlinux.org>; Fri, 18 Feb 2011 17:31:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
h=domainkey-signature:from:to:cc:subject:date:message-id:x-mailer
:in-reply-to:references:mime-version:content-type
:content-transfer-encoding;
bh=qhK5Z19sH1ZmJpzItbx6TKq8G0HHm/6Q6u85zxVBXeU=;
b=aOLqJwpZliYxWins3Nm4BUod9vrVZpI5yKLfQSWPygY79aQw Fx+YItqypjDMjOs6HC
nrEXRxBTzLrYmwxEMzNLHYFGOBOhvbVE5Y3aA/7XTWDjTgzIWKh6/Pk3A8jBVasmx9yd
MNEA/lSNHLN9qFPSRSoB8sZBnr/3iOo21FVxU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
h=from:to:cc:subject:date:message-id:x-mailer:in-reply-to:references
:mime-version:content-type:content-transfer-encoding;
b=cDu/7i4JsEPc21yATAHymw4Fg6hebb5cP+FeDH0FRdlf/HGWfdt5vYWRGVA3wMDg2s
dGfOZVpMLslazMpRjkJKqpGAw+jefWfKc148Viw6loJXM9xsIk j6gym8RQ7U6yxtFljC
LiJG748ePRYfwZvy8u7Hy8437eFXAfdNo9x4Y=
Received: by 10.236.105.199 with SMTP id k47mr2561926yhg.90.1298079107146;
Fri, 18 Feb 2011 17:31:47 -0800 (PST)
Received: from localhost ([201.80.187.151])
by mx.google.com with ESMTPS id z5sm1748307yhc.35.2011.02.18.17.31.42
(version=TLSv1/SSLv3 cipher=OTHER);
Fri, 18 Feb 2011 17:31:46 -0800 (PST)
From: =?UTF-8?q?Denis=20A=2E=20Alto=C3=A9=20Falqueto?=
<denisfalqueto@gmail.com>
To: pacman-dev@archlinux.org
Date: Fri, 18 Feb 2011 23:30:23 -0200
Message-Id: <1298079023-28529-4-git-send-email-denisfalqueto@gmail.com>
X-Mailer: git-send-email 1.7.4.1
In-Reply-To: <1298079023-28529-1-git-send-email-denisfalqueto@gmail.com>
References: <1298079023-28529-1-git-send-email-denisfalqueto@gmail.com>
MIME-Version: 1.0
Subject: [pacman-dev] [PATCH 3/3] pacman-key: better handling of options and
supressing gpg output
X-BeenThere: pacman-dev@archlinux.org
X-Mailman-Version: 2.1.14
Precedence: list
Reply-To: Discussion list for pacman development <pacman-dev@archlinux.org>
List-Id: Discussion list for pacman development <pacman-dev.archlinux.org>
List-Unsubscribe: <http://mailman.archlinux.org/mailman/options/pacman-dev>,
<mailtoacman-dev-request@archlinux.org?subject=unsubscribe>
List-Archive: <http://mailman.archlinux.org/pipermail/pacman-dev>
List-Post: <mailtoacman-dev@archlinux.org>
List-Help: <mailtoacman-dev-request@archlinux.org?subject=help>
List-Subscribe: <http://mailman.archlinux.org/mailman/listinfo/pacman-dev>,
<mailtoacman-dev-request@archlinux.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Errors-To: pacman-dev-bounces@archlinux.org
Sender: pacman-dev-bounces@archlinux.org

VGhlIG9wdGlvbiAtLXRydXMgd2FzIGNoYW5nZWQgdG8gLS1lZG l0LWtleSwgZm9yIGJldHRlciBh
bGlnbm1lbnQKd2l0aCB0aGUgdW5kZXJseWluZyAtLWVkaXQta2 V5IG9mIGdudXBnLgoKVGhlIG9w
dGlvbnMgLS1jb25maWcgYW5kIC0tZ3BnZGlyIHdlcmUgbm90IG JlaW5nIGhhbmRsZWQgY29ycmVj
dGx5LgpUaGV5IHdvdWxkIG5vdCB3b3JrIGlmIHdlcmUgbm90IH VzZWQgYXMgZmlyc3QgYXJndW1l
bnRzIGFsd2F5cy4KTm93IHRoZSBoYW5kbGluZyBpcyBtb3JlIG ZsZXhpYmxlLgoKVGhlIHVzZSBv
ZiBncGcgZm9yIHZlcmlmaWNhdGlvbiBwdXJwb3NlcyB3YXMgbG Vha2luZyBpbmNvbnZlbmllbnQK
bWVzc2FnZXMgdG8gdGhlIG91dHB1dCwgc28gdGhleSB3ZXJlIH F1aWV0ZWQgd2l0aCAtLXF1aWV0
LAoxPi9kZXYvbnVsbCBhbmQgMj4mMS4KClNpZ25lZC1vZmYtYn k6IERlbmlzIEEuIEFsdG/DqSBG
YWxxdWV0byA8ZGVuaXNmYWxxdWV0b0BnbWFpbC5jb20+Ci0tLQ ogZG9jL3BhY21hbi1rZXkuOC50
eHQgICAgIHwgICAgNCArLQogc2NyaXB0cy9wYWNtYW4ta2V5Ln NoLmluIHwgICA1NSArKysrKysr
KysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS 0tCiAyIGZpbGVzIGNoYW5nZWQs
IDM4IGluc2VydGlvbnMoKyksIDIxIGRlbGV0aW9ucygtKQoKZG lmZiAtLWdpdCBhL2RvYy9wYWNt
YW4ta2V5LjgudHh0IGIvZG9jL3BhY21hbi1rZXkuOC50eHQKaW 5kZXggNWViYmQwYS4uYmE5N2I4
MiAxMDA2NDQKLS0tIGEvZG9jL3BhY21hbi1rZXkuOC50eHQKKy srIGIvZG9jL3BhY21hbi1rZXku
OC50eHQKQEAgLTU5LDggKzU5LDggQEAgQ29tbWFuZHMKICpcLS 1yZWxvYWQqOjoKIAlSZWxvYWRz
IHRoZSBrZXlzIGZyb20gdGhlIGtleXJpbmcgcGFja2FnZQogCi 0qLXQqLCAqXC0tdHJ1c3QqICdr
ZXlpZCc6OgotCVNldCB0aGUgdHJ1c3QgbGV2ZWwgb2YgdGhlIG dpdmVuIGtleQorKi10KiwgKlwt
LWVkaXQta2V5KiAna2V5aWQgLi4uJzo6CisJRWRpdCB0cnVzdC Bwcm9wZXJ0aWVzIGZvciB0aGUg
Z2l2ZW4ga2V5cwogCiAqLXUqLCAqXC0tdXBkYXRlZGIqOjoKIA lFcXVpdmFsZW50IHRvIFwtLWNo
ZWNrLXRydXN0ZGIgaW4gR251UEcKZGlmZiAtLWdpdCBhL3Njcm lwdHMvcGFjbWFuLWtleS5zaC5p
biBiL3NjcmlwdHMvcGFjbWFuLWtleS5zaC5pbgppbmRleCBjY2 FmNGIyLi5kOTdiMDcxIDEwMDY0
NAotLS0gYS9zY3JpcHRzL3BhY21hbi1rZXkuc2guaW4KKysrIG Ivc2NyaXB0cy9wYWNtYW4ta2V5
LnNoLmluCkBAIC03MSw3ICs3MSw3IEBAIHVzYWdlKCkgewogCW VjaG8gIiQoZ2V0dGV4dCAiICAt
bCB8IC0tbGlzdCAgICAgICAgICAgICAgICAgICAgICAgICAgIC AtIGxpc3Qga2V5cyIpIgogCWVj
aG8gIiQoZ2V0dGV4dCAiICAtciB8IC0tcmVjZWl2ZSA8a2V5c2 VydmVyPiA8a2V5aWQ+IC4uLiAt
IGZldGNoIHRoZSBrZXlpZHMgZnJvbSB0aGUgc3BlY2lmaWVkIi kiCiAJZWNobyAiJChnZXR0ZXh0
ICIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC AgICAgICAga2V5c2VydmVyIFVS
TCIpIgotCWVjaG8gIiQoZ2V0dGV4dCAiICAtdCB8IC0tdHJ1c3 QgPGtleWlkPiAuLi4gICAgICAg
ICAgICAgICAtIHNldCB0aGUgdHJ1c3QgbGV2ZWwgb2YgdGhlIG dpdmVuIGtleSIpIgorCWVjaG8g
IiQoZ2V0dGV4dCAiICAtdCB8IC0tZWRpdC1rZXkgPGtleWlkPi AuLi4gICAgICAgICAgICAtIGVk
aXQgdHJ1c3QgcHJvcGVydGllcyBmb3IgdGhlIGdpdmVuIGtleX MiKSIKIAllY2hvICIkKGdldHRl
eHQgIiAgLXUgfCAtLXVwZGF0ZWRiICAgICAgICAgICAgICAgIC AgICAgICAgLSB1cGRhdGUgdGhl
IHRydXN0ZGIgb2YgcGFjbWFuIikiCiAJZWNobyAiJChnZXR0ZX h0ICIgIC12IHwgLS12ZXJzaW9u
ICAgICAgICAgICAgICAgICAgICAgICAgIC0gZGlzcGxheXMgdG hlIGN1cnJlbnQgdmVyc2lvbiIp
IgogCWVjaG8gIiQoZ2V0dGV4dCAiICAtLWFkdiA8cGFyYW1zPi AgICAgICAgICAgICAgICAgICAg
ICAgICAtIHVzZSBwYWNtYW4ncyBrZXlyaW5nIGFzIHRhcmdldC Bmb3IiKSIKQEAgLTExNyw3ICsx
MTcsNyBAQCByZWxvYWRfa2V5cmluZygpIHsKIAkjIFZlcmlmeS BzaWduYXR1cmVzIG9mIHJlbGF0
ZWQgZmlsZXMsIGlmIHRoZXkgZXhpc3QKIAlpZiBbWyAtciAiJH tBRERFRF9LRVlTfSIgXV07IHRo
ZW4KIAkJbXNnICIkKGdldHRleHQgIlZlcmlmeWluZyBvZmZpY2 lhbCBrZXlzIGZpbGUgc2lnbmF0
dXJlLi4uIikiCi0JCWlmICEgJHtHUEdfUEFDTUFOfSAtLXF1aW V0IC0tYmF0Y2ggLS12ZXJpZnkg
IiR7QURERURfS0VZU30uc2lnIiAxPi9kZXYvbnVsbDsgdGhlbg orCQlpZiAhICR7R1BHX1BBQ01B
Tn0gLS1xdWlldCAtLXZlcmlmeSAiJHtBRERFRF9LRVlTfS5zaW ciIDE+L2Rldi9udWxsIDI+JjE7
IHRoZW4KIAkJCWVycm9yICIkKGdldHRleHQgIlRoZSBzaWduYX R1cmUgb2YgZmlsZSAlcyBpcyBu
b3QgdmFsaWQuIikiICIke0FEREVEX0tFWVN9IgogCQkJZXhpdC AxCiAJCWZpCkBAIC0xMjUsNyAr
MTI1LDcgQEAgcmVsb2FkX2tleXJpbmcoKSB7CiAKIAlpZiBbWy AtciAiJHtERVBSRUNBVEVEX0tF
WVN9IiBdXTsgdGhlbgogCQltc2cgIiQoZ2V0dGV4dCAiVmVyaW Z5aW5nIGRlcHJlY2F0ZWQga2V5
cyBmaWxlIHNpZ25hdHVyZS4uLiIpIgotCQlpZiAhICR7R1BHX1 BBQ01BTn0gLS1xdWlldCAtLWJh
dGNoIC0tdmVyaWZ5ICIke0RFUFJFQ0FURURfS0VZU30uc2lnIi AxPi9kZXYvbnVsbDsgdGhlbgor
CQlpZiAhICR7R1BHX1BBQ01BTn0gLS1xdWlldCAtLXZlcmlmeS AiJHtERVBSRUNBVEVEX0tFWVN9
LnNpZyIgMT4vZGV2L251bGwgMj4mMTsgdGhlbgogCQkJZXJyb3 IgIiQoZ2V0dGV4dCAiVGhlIHNp
Z25hdHVyZSBvZiBmaWxlICVzIGlzIG5vdCB2YWxpZC4iKSIgIi R7REVQUkVDQVRFRF9LRVlTfSIK
IAkJCWV4aXQgMQogCQlmaQpAQCAtMTMzLDcgKzEzMyw3IEBAIH JlbG9hZF9rZXlyaW5nKCkgewog
CiAJaWYgW1sgLXIgIiR7UkVNT1ZFRF9LRVlTfSIgXV07IHRoZW 4KIAkJbXNnICIkKGdldHRleHQg
IlZlcmlmeWluZyBkZWxldGVkIGtleXMgZmlsZSBzaWduYXR1cm UuLi4iKSIKLQkJaWYgISAke0dQ
R19QQUNNQU59IC0tcXVpZXQgLS1iYXRjaCAtLXZlcmlmeSAiJH tSRU1PVkVEX0tFWVN9LnNpZyI7
IHRoZW4KKwkJaWYgISAke0dQR19QQUNNQU59IC0tcXVpZXQgLS 12ZXJpZnkgIiR7UkVNT1ZFRF9L
RVlTfS5zaWciIDE+L2Rldi9udWxsIDI+JjE7IHRoZW4KIAkJCW Vycm9yICIkKGdldHRleHQgIlRo
ZSBzaWduYXR1cmUgb2YgZmlsZSAlcyBpcyBub3QgdmFsaWQuIi kiICIke1JFTU9WRURfS0VZU30i
CiAJCQlleGl0IDEKIAkJZmkKQEAgLTIyOSwxNSArMjI5LDI3IE BAIGlmIFtbICQxICE9ICItLXZl
cnNpb24iICYmICQxICE9ICItdiIgJiYgJDEgIT0gIi0taGVscC IgJiYgJDEgIT0gIi1oIiAmJiAk
MSAhPSAiCiAJZmkKIGZpCiAKLSMgUGFyc2UgZ2xvYmFsIG9wdG lvbnMKKyMgSXRlcmF0ZSBvdmVy
IHRoZSBwYXJhbWV0ZXJzIHRvIGdldCAtLWNvbmZpZyBhbmQgLS 1ncGdkaXIKKyMgVGhpcyB0aW1l
LCB0aGUgcGFyYW1ldGVycyB3aWxsIG5vdCBiZSBjb25zdW1lZC 4gVGhpcyBpcyBuZWVkZWQKKyMg
YmVjYXVzZSB0aGUgY29kZSBuZWVkcyB0byBrbm93IHdoZXJlIG lzIHBhY21hbidzIGtleXJpbmcg
YmVmb3JlCisjIHNpZ25pbmcgb3IgdmVyaWZ5aW5nIGFueSBmaW xlcy4KIENPTkZJRz0iQHN5c2Nv
bmZkaXJAL3BhY21hbi5jb25mIgotUEFDTUFOX0tFWVJJTkdfRE lSPSJAc3lzY29uZmRpckAvcGFj
bWFuLmQvZ251cGciCi13aGlsZSBbWyAkMSA9fiBeLS0oY29uZm lnfGdwZ2RpcikkIF1dOyBkbwot
CWNhc2UgIiQxIiBpbgotCQktLWNvbmZpZykgc2hpZnQ7IENPTk ZJRz0iJDEiIDs7Ci0JCS0tZ3Bn
ZGlyKSBzaGlmdDsgUEFDTUFOX0tFWVJJTkdfRElSPSIkMSIgOz sKK0dQR0RJUj0iIgoraXNjb25m
aWc9MAoraXNncGdkaXI9MAorZm9yIGFyZyBpbiAiJEAiOyBkbw orCWlmICgoIGlzY29uZmlnICkp
OyB0aGVuCisJCWlzY29uZmlnPTAKKwkJQ09ORklHPSIkYXJnIg orCWZpCisJaWYgKCggaXNncGdk
aXIgKSk7IHRoZW4KKwkJaXNncGdkaXI9MAorCQlHUEdESVI9Ii RhcmciCisJZmkKKwljYXNlICIk
YXJnIiBpbgorCQktLWNvbmZpZykgaXNjb25maWc9MTs7CisJCS 0tZ3BnZGlyKSBpc2dwZ2Rpcj0x
OzsKIAllc2FjCi0Jc2hpZnQKIGRvbmUKIAogaWYgW1sgISAtci AiJHtDT05GSUd9IiBdXTsgdGhl
bgpAQCAtMjQ2LDExICsyNTgsMTMgQEAgaWYgW1sgISAtciAiJH tDT05GSUd9IiBdXTsgdGhlbgog
ZmkKIAogIyBSZWFkIEdQR0RJUiBmcm9tICRDT05GSUcuCi0jIF RoZSBwYXR0ZXJuIGlzOiBhbnkg
c3BhY2VzIG9yIHRhYnMsIEdQR0RpciwgYW55IHNwYWNlcyBvci B0YWJzLCBlcXVhbCBzaWduCi0j
IGFuZCB0aGUgcmVzdCBvZiB0aGUgbGluZS4gVGhlIHN0cmluZy BpcyBzcGxpdHRlZCBhZnRlciB0
aGUgZmlyc3Qgb2NjdXJyZW5jZSBvZiA9Ci1pZiBbWyBHUEdESV I9JChmaW5kX2NvbmZpZyAiR1BH
RGlyIikgPT0gMCBdXTsgdGhlbgotCVBBQ01BTl9LRVlSSU5HX0 RJUj0iJHtHUEdESVJ9IgotZmkK
KyMgVGhlIHByZWNlZGVuY2UgZm9yIEdQR0RJUiBpczoKKyMgMX N0OiBjb21tYW5kIGxpbmUKKyMg
Mm5kOiBwYWNtYW4uY29uZgorIyAzcmQ6IGRlZmF1bHQgdmFsdW UKK1tbIC16ICIkR1BHRElSIiBd
XSAmJiBHUEdESVI9JChmaW5kX2NvbmZpZyAiR1BHRGlyIikKK1 tbIC16ICIkR1BHRElSIiBdXSAm
JiBHUEdESVI9IkBzeXNjb25mZGlyQC9wYWNtYW4uZC9nbnVwZy IKK1BBQ01BTl9LRVlSSU5HX0RJ
Uj0iJHtHUEdESVJ9IgogR1BHX1BBQ01BTj0iZ3BnIC0taG9tZW RpciAke1BBQ01BTl9LRVlSSU5H
X0RJUn0iCiAKICMgUGFyc2UgYW5kIGV4ZWN1dGUgY29tbWFuZA pAQCAtMjgxLDEwICsyOTUsMTAg
QEAgY2FzZSAiJHtjb21tYW5kfSIgaW4KIAkJcmVsb2FkX2tleX JpbmcKIAkJOzsKIAktbHwtLWxp
c3QpCi0JCSR7R1BHX1BBQ01BTn0gLS1iYXRjaCAtLWxpc3Qtc2 lncyAiJEAiCisJCSR7R1BHX1BB
Q01BTn0gLS1saXN0LXNpZ3MgIiRAIgogCQk7OwogCS1mfC0tZm luZ2VyKQotCQkke0dQR19QQUNN
QU59IC0tYmF0Y2ggLS1maW5nZXJwcmludCAkKgorCQkke0dQR1 9QQUNNQU59IC0tZmluZ2VycHJp
bnQgJCoKIAkJOzsKIAktZXwtLWV4cG9ydCkKIAkJJHtHUEdfUE FDTUFOfSAtLWFybW9yIC0tZXhw
b3J0ICIkQCIKQEAgLTI5OSw3ICszMTMsNyBAQCBjYXNlICIke2 NvbW1hbmR9IiBpbgogCQlzaGlm
dAogCQkke0dQR19QQUNNQU59IC0ta2V5c2VydmVyICIke2tleX NlcnZlcn0iIC0tcmVjdi1rZXlz
ICIkQCIKIAkJOzsKLQktdHwtLXRydXN0KQorCS10fC0tZWRpdC 1rZXkpCiAJCWlmICgoICQjID09
IDAgKSk7IHRoZW4KIAkJCWVycm9yICIkKGdldHRleHQgIllvdS BuZWVkIHRvIHNwZWNpZnkgYXQg
bGVhc3Qgb25lIGtleSBpZGVudGlmaWVyIikiCiAJCQl1c2FnZQ pAQCAtMzI4LDYgKzM0Miw5IEBA
IGNhc2UgIiR7Y29tbWFuZH0iIGluCiAJCXZlcnNpb24KIAkJZX hpdCAwCiAJCTs7CisJIyBQYXJh
bWV0ZXJzIGFscmVhZHkgaGFuZGxlZAorCS0tY29uZmlnKSBzaG lmdCA7OworCS0tZ3BnZGlyKSBz
aGlmdCA7OwogCSopCiAJCXVzYWdlCiAJCWV4aXQgMQotLSAKMS 43LjQuMQoKCg==

On Sat, 19 Feb 2011 11:21:47 +1000
Allan McRae <allan@archlinux.org> wrote:
> We are using gpgme which is maintained by gpg developers. So we are
> not reinventing any wheel. If that is an ill-maintained and contains
> security issues, then why trust gpg at all?

I'm not up on the latest in gpg, what is being developed, or how well it has been cryptographically tested, and it sounds like you're not either to some extent. I was offering general suggestions - try to see the bigger picture and the details won't be so much work. I still think using command line gpg gives users better control over their own security solutions and provides better security. But you're obviously too deeply invested in the libraries now to even consider anything else (which is one reason why I advise against them). So be it.

> Have you actually looked at the current implementation at all?

I read some discussions of it, but I have not looked at it. Frankly it interests me far less than having signatures available at this point. I trust that you can implement checking. I think you're putting the cart before the horse, which is why package signing is getting nowhere (no real usable results). But if you have kept it as simple as you describe, good work.

> In the end, the only way anything will get implemented is if patches
> are provided. (That includes the suggestion of providing signatures
> in repos on Arch Linux - look at that devtools/db-scripts projects).
> Dan and I have also mentioned our consulting rates in the past, which
> may or may not increase motivation to finish this...

Surely you have some mechanism in makepkg or elsewhere for generating the signatures used in your test repo for your pacman sig checking features. Why not push this through to the packaging or database tools now while you're still working on pacman? Or have you completely ignored the need to generate signatures (I know you haven't from what I've read, so that's rhetorical).

It seems you or others are stalling on providing signatures because you want exclusive control of checking those signatures. It's trivial to implement providing them and surely you know that - man gpg for help. Like everything done by committee, I think you're making things more complicated than they need to be. It's okay, I didn't have high hopes for this communication. This issue is obviously too mired in politics and ego for anything to budge (not you personally).

> Finally, *succinct* reports on where the current implementation in
> pacman can be improved are also appreciated. But that requires
> actually paying attention to what has already been done.

Agreed. FWIW, I think your pacman changes will see reality (as in popular use) much more quickly if signatures show up on mirrors sooner rather than later. Once the sigs are there, the appetite for your pacman work will be there, and the dev politics of Arch will sway.

Simply put, there can be no logical or technical reason for not providing signatures for packages. At the minimum, they can only vastly improve the situation, which currently is a complete abdication of any form of responsible package security, and they are trivial to add. The only reason for not providing them is a human one - IOW irrational. I'm no diplomat - I just make things work. I'll leave you to your politics.

On Sat, Feb 19, 2011 at 12:00 AM, IgnorantGuru
<jgj7.pacmandev@mailnull.com> wrote:
> [.... lots of talk....]

There's no political problems here. It's just lack of manpower to make
it. That's it. This is a standard open source community, there's just
momentum when there is personal interest.

In the other hand, I kind of enjoy your stimulus, because I'm just so
lazy..... Sometime I need some push over to make me do things
Sorry, but it's the truth.

--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-------------------------------------------
Denis A. Altoe Falqueto
Linux user #524555
-------------------------------------------

On 19/02/11 12:00, IgnorantGuru wrote:

On Sat, 19 Feb 2011 11:21:47 +1000
Allan McRae<allan@archlinux.org> wrote:

We are using gpgme which is maintained by gpg developers. So we are
not reinventing any wheel. If that is an ill-maintained and contains
security issues, then why trust gpg at all?


I'm not up on the latest in gpg, what is being developed, or how well it has been cryptographically tested, and it sounds like you're not either to some extent. I was offering general suggestions - try to see the bigger picture and the details won't be so much work. I still think using command line gpg gives users better control over their own security solutions and provides better security. But you're obviously too deeply invested in the libraries now to even consider anything else (which is one reason why I advise against them). So be it.


We are not too deeply invested in anything. No release has been made...
I was just pointed out that you appear to have no idea what the
library we are using is and what it actually does. It makes absolutely
no sense to have pacman manually fork a process to run gpg to verify a
package/database and then manually parse the output when the upstream
gpg developers provide a library to do just that.



Have you actually looked at the current implementation at all?


I read some discussions of it, but I have not looked at it. Frankly it interests me far less than having signatures available at this point. I trust that you can implement checking. I think you're putting the cart before the horse, which is why package signing is getting nowhere (no real usable results). But if you have kept it as simple as you describe, good work.


In the end, the only way anything will get implemented is if patches
are provided. (That includes the suggestion of providing signatures
in repos on Arch Linux - look at that devtools/db-scripts projects).
Dan and I have also mentioned our consulting rates in the past, which
may or may not increase motivation to finish this...


Surely you have some mechanism in makepkg or elsewhere for generating the signatures used in your test repo for your pacman sig checking features. Why not push this through to the packaging or database tools now while you're still working on pacman? Or have you completely ignored the need to generate signatures (I know you haven't from what I've read, so that's rhetorical).

It seems you or others are stalling on providing signatures because you want exclusive control of checking those signatures. It's trivial to implement providing them and surely you know that - man gpg for help. Like everything done by committee, I think you're making things more complicated than they need to be. It's okay, I didn't have high hopes for this communication. This issue is obviously too mired in politics and ego for anything to budge (not you personally).


Design by committee implies there is an actually committee making
decisions around here, which is far from the truth...


The reason the makepkg changes have not been pushed yet is because they
are not finished. As someone who has run the gpg branch version of
makepkg for a while, I found it really annoying to not be able to
disable/enable signing from the command line. I see Denis just sent a
patch for that so it may be possible to push the makepkg changes in the
future. But that is very unlikely to happen before the next release
which is scheduled to occur quite soon.


Offtopic: Not that this actually matters as far as Arch Linux is
concerned. The support needs added to devtools/db-scripts. The package
upload script could have a temporary line in it to do the package
signing while waiting on makepkg to do that automatically.



Finally, *succinct* reports on where the current implementation in
pacman can be improved are also appreciated. But that requires
actually paying attention to what has already been done.


Agreed. FWIW, I think your pacman changes will see reality (as in popular use) much more quickly if signatures show up on mirrors sooner rather than later. Once the sigs are there, the appetite for your pacman work will be there, and the dev politics of Arch will sway.

Simply put, there can be no logical or technical reason for not providing signatures for packages. At the minimum, they can only vastly improve the situation, which currently is a complete abdication of any form of responsible package security, and they are trivial to add. The only reason for not providing them is a human one - IOW irrational. I'm no diplomat - I just make things work. I'll leave you to your politics.


I'll repeat, talk to the providers of the repos about getting signatures
provided. This list is for pacman-development only and thus any
distribution specific conversation is off-topic.. But to be the guy who
"makes things work", patches will be required.


Allan

The mail by IgnorantGuru is very much what I was going to write. There
is no problem in adding signatures to the Arch repositories immediately.

You always say that pacman is not the same as Arch. This might be true,
but which major distribution uses pacman? We should not argue about
those subtile differences.

I pulled the main pacman branch, merged Allan's gpg-patches and created
a signed repository - everything worked fine (Except for example
overwriting the db with a unverified one before verifing - I can provide
patches for this in one week). You always say that you need patches, but
what exactly? You seem to have a working implementation but you don't
integrate these into master. Instead you work on minor performance
issues (Single file database for example) even though we have a very
serious security problem.

Regards
Daniel

On 19/02/11 15:18, Daniel Mendler wrote:

The mail by IgnorantGuru is very much what I was going to write. There
is no problem in adding signatures to the Arch repositories immediately.

You always say that pacman is not the same as Arch. This might be true,
but which major distribution uses pacman? We should not argue about
those subtile differences.

I pulled the main pacman branch, merged Allan's gpg-patches and created
a signed repository - everything worked fine (Except for example
overwriting the db with a unverified one before verifing - I can provide
patches for this in one week). You always say that you need patches, but
what exactly? You seem to have a working implementation but you don't
integrate these into master. Instead you work on minor performance
issues (Single file database for example) even though we have a very
serious security problem.


I will repeat myself again... Patches for pacman do bugger all for
getting signatures into Arch Linux repos. Patches for the Arch Linux
devtools/db-scripts packages are needed.


And I will once again point to the package signing TODO page for a list
of what we need to do at a minimum before this becomes integrated in the
main pacman branch:

https://wiki.archlinux.org/index.php/User:Allan/Package_Signing
As with all feature branches, they integrated into master when they are
finished. Otherwise we can not make a release without actually getting
it fully completed or backing out the unfinished work. Given the rate
this has been developed, the second seems the likely outcome.


Finally, "minor" performance issues interest me a hell of a lot more
than package signing. Mainly because that actually affects me whereas
unsigned packages really does not... That is why I spent my free time
implementing them. Thinking about it, improving optdepends handling,
transaction hooks, VCS support in makepkg, adding a test suite for
makepkg, automatic creation of debug packages, .... all affect me more
than package signing does, so I maybe will start work on package signing
again once those are finished.


Allan

On Sat, 19 Feb 2011 17:35:21 +1000, Allan McRae wrote:
> I will repeat myself again... Patches for pacman do bugger all for
> getting signatures into Arch Linux repos. Patches for the Arch Linux
> devtools/db-scripts packages are needed.

To be honest, I don't think it's worth to work on patches for devtools
dbscripts right now. I'd prefer to be pointed at some documents which
describe exactly the wrokflow to sign a package with makepkg, upload it,
add it to a db, update, replace and delete it.

Once there is a version of pacman which supports signed packages I can
start implementing these ideas.

And last but not least we need to think about key management which is
less technical but very important.

Greetings,

Pierre

--
Pierre Schmitz, https://users.archlinux.de/~pierre

Hi Allan

> I will repeat myself again... Patches for pacman do bugger all for
> getting signatures into Arch Linux repos. Patches for the Arch Linux
> devtools/db-scripts packages are needed.

Well, Pierre says the same for pacman. Someone has to take the first
initiative here.

> And I will once again point to the package signing TODO page for a list
> of what we need to do at a minimum before this becomes integrated in the
> main pacman branch:
> https://wiki.archlinux.org/index.php/User:Allan/Package_Signing
> As with all feature branches, they integrated into master when they are
> finished. Otherwise we can not make a release without actually getting
> it fully completed or backing out the unfinished work. Given the rate
> this has been developed, the second seems the likely outcome.

I understand that it should be finished before it is merged. What is
missing is a strong statement from the development team that they want
signatures asap. I think there are enough people who are willing to
provide patches (me included) if you show real interest in package signing.

> Finally, "minor" performance issues interest me a hell of a lot more
> than package signing. Mainly because that actually affects me whereas
> unsigned packages really does not... That is why I spent my free time
> implementing them. Thinking about it, improving optdepends handling,
> transaction hooks, VCS support in makepkg, adding a test suite for
> makepkg, automatic creation of debug packages, .... all affect me more
> than package signing does, so I maybe will start work on package signing
> again once those are finished.

You really have to rethink your priority list here. Those attacks on
package managers are known for a long time and the package signing point
has come up very often on the pacman mailing list. So there are people
who are concerned about it.

Daniel

On Sat, 19 Feb 2011 12:38:07 +1000
Allan McRae <allan@archlinux.org> wrote:

> It makes
> absolutely no sense to have pacman manually fork a process to run gpg
> to verify a package/database and then manually parse the output when
> the upstream gpg developers provide a library to do just that.

Perhaps if you look at it from a different perspective, it will make sense to you. This is what I meant by code efficiency not always being optimum in security dev. I still think you've already precluded another solution, but I'll see if I can enlighten you on what I'm getting at.

If pacman forks a call to gpg using a command line, it is transparent. I can replace gpg with a script and catch the call, examine it, log it, even alter the text stream returned to see how pacman reacts. I can do this on an executable of unknown origin and with possibly tampered source, without needed the source. I can even use a custom gpg or wrapper script to do other things you and I aren't able to anticipate right now - it is open-ended. The interprocess communication is open, flexible, and transparent. That is why linux programs operate on the command line and on text streams - it makes for transparency and flexibility.

Check out
http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy
In particular, ponder how these might apply, doubly so in security:
4. Choose portability over efficiency.
5. Store data in flat text files.
6. Use shell scripts to increase leverage and portability.
8. Avoid captive user interfaces.
9. Make every program a filter.

And especially:
1a. Allow the user to tailor the environment.

In addition, if I want to sabotage the source, API calls make for easy hiding of changes that may not be detected, whereas changing command line usage makes a lot of noise and can be detected. Will you notice one value changed in 10,000 lines to create a buffer overrun where I can later inject traceless code? Probably not. In sophisticated security breaches, that's how things are done. They're 'accidents' which can later be denied if discovered. Let's see you deny changing the keyring used on the command line.

That's just a small sample of why open and flexible interprocess communication is valuable in security dev. That's not to say it's always done this way - far from it, sometimes with ulterior motives.

> Finally, "minor" performance issues interest me a hell of a lot more than package signing.

Obvious Allan, you don't understand the importance of package signing and with that poor attitude and lack of awareness I don't think you should be working on security at all. All you're apparently doing is sabotaging it by procrastinating. Obviously you're the type that needs to see a huge security breach in Arch to understand the importance of this. And even without a huge breach, unsigned packages create a local lack of security for admins. Which part of this aren't you getting? Why do you think Microsoft bothers to sign their updates? Just for the heck of it? (Sad that in this case Microsoft is being used as an example of good security practice - that's how out of line Arch's package security is.)

It's great when one of the devs responsible for package signing announces he doesn't care about package signing, it's just stupid. Very professional. I'll not be contracting your services, thanks.

> I found it really annoying to not be able to
> disable/enable signing from the command line.

While I might agree, you seem to find this whole package security subject "really annoying" and too much trouble to bother with.

I find a disconcerting lack of good security practices in Arch, and I'm beginning to see why.

> But to be the guy who "makes things work", patches will be required.

Interesting that you think so, because patches are the way to make non-secure junk. The way to make things work is for the person most familiar with the code and protocols to make those changes rather than him begging others to write ill-fitting patches. Patches are also a big waste of time because what someone familiar with the code can do in a few minutes (and do well) may take hours of research for someone unfamiliar (to do poorly). Talk about efficiency - try applying it to your work in larger ways. Maybe that's one reason why it takes you so long to develop - you're unwilling to take on responsibility for the project as a whole. You definitely seem a very reluctant and whining freeware developer. Get over yourself and put some quality into your work, regardless of what you're paid or not paid. Or don't - in which case you're not worth your complaining.