[pacman-dev] [PATCH] (newgpg) Let pacman specify GnuPG's home directory.
GnuPG looks for configuration files and keyrings in its home directory. For a user, that is typically ~/.gnupg. This patch causes pacman to use /etc/pacman.d/gnupg/ as the default GnuPG home. One may override the default using --gpgdir on the command-line or GPGDir in pacman's configuration file. Signed-off-by: Chris Brannon <cmbrannon@cox.net> --- doc/pacman.8.txt | 7 +++++++ doc/pacman.conf.5.txt | 6 ++++++ src/pacman/Makefile.am | 2 ++ src/pacman/conf.h | 1 + src/pacman/pacman.c | 25 +++++++++++++++++++++++++ 5 files changed, 41 insertions(+), 0 deletions(-) diff --git a/doc/pacman.8.txt b/doc/pacman.8.txt index 6f071ba..a780627 100644 --- a/doc/pacman.8.txt +++ b/doc/pacman.8.txt @@ -136,6 +136,13 @@ Options *\--config* <'file'>:: Specify an alternate configuration file. +*\--gpgdir* <'dir':: + Specify a directory of files used by GnuPG to verify package + signatures. This directory should contain two files: + ``pubring.gpg'' and ``trustdb.gpg''. ``pubring.gpg'' holds the public + keys of all packagers. ``trustdb.gpg'' contains a so-called + trust database, which specifies that the keys are authentic and trusted. + *\--logfile* <'file'>:: Specify an alternate log file. This is an absolute path, regardless of the installation root setting. diff --git a/doc/pacman.conf.5.txt b/doc/pacman.conf.5.txt index 8ef11ec..fa69bfa 100644 --- a/doc/pacman.conf.5.txt +++ b/doc/pacman.conf.5.txt @@ -69,6 +69,12 @@ Options path, the root path is not automatically prepended. +*GPGDir =* path/to/gpg/dir:: + Overrides the default location of the directory containing + configuration files for GnuPG. + A typical default is ``/etc/pacman.d/gnupg''. + This is an absolute path, and the root directory is not prepended. + *LogFile =* '/path/to/file':: Overrides the default location of the pacman log file. A typical default is ``/var/log/pacman.log''. This is an absolute path and the root directory diff --git a/src/pacman/Makefile.am b/src/pacman/Makefile.am index 220ee9c..4da6ef3 100644 --- a/src/pacman/Makefile.am +++ b/src/pacman/Makefile.am @@ -1,6 +1,7 @@ # paths set at make time conffile = ${sysconfdir}/pacman.conf dbpath = ${localstatedir}/lib/pacman/ +gpgdir = ${sysconfdir}/pacman.d/gnupg/ cachedir = ${localstatedir}/cache/pacman/pkg/ logfile = ${localstatedir}/log/pacman.log @@ -10,6 +11,7 @@ DEFS = -DLOCALEDIR=\"@localedir@\" \ -DCONFFILE=\"$(conffile)\" \ -DROOTDIR=\"$(ROOTDIR)\" \ -DDBPATH=\"$(dbpath)\" \ + -DGPGDIR=\"$(gpgdir)\" \ -DCACHEDIR=\"$(cachedir)\" \ -DLOGFILE=\"$(logfile)\" \ @DEFS@ diff --git a/src/pacman/conf.h b/src/pacman/conf.h index 8ea6662..f491057 100644 --- a/src/pacman/conf.h +++ b/src/pacman/conf.h @@ -37,6 +37,7 @@ typedef struct __config_t { char *rootdir; char *dbpath; char *logfile; + char *gpgdir; /* TODO how to handle cachedirs? */ unsigned short op_q_isfile; diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index 3255cdf..18fd3a8 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -138,6 +138,7 @@ static void usage(int op, const char * const myname) printf(_(" -q, --quiet show less information for query and search\n")); } printf(_(" --config <path> set an alternate configuration file\n")); + printf(_(" --gpgdir <path> set an alternate home directory for GnuPG\n")); printf(_(" --logfile <path> set an alternate log file\n")); printf(_(" --noconfirm do not ask for any confirmation\n")); printf(_(" --noprogressbar do not show a progress bar when downloading files\n")); @@ -306,6 +307,20 @@ static void setlibpaths(void) } } + /* + * Set GnuPG's home directory. This is not relative to + * rootdir, even if rootdir is defined. + * Reasoning: gpgdir contains configuration data. +*/ + if(config->gpgdir) { + ret = alpm_option_set_signaturedir(config->gpgdir); + if(ret != 0) { + pm_printf(PM_LOG_ERROR, _("problem setting gpgdir '%s' (%s)\n"), + config->gpgdir, alpm_strerrorlast()); + cleanup(ret); + } + } + /* add a default cachedir if one wasn't specified */ if(alpm_option_get_cachedirs() == NULL) { alpm_option_add_cachedir(CACHEDIR); @@ -366,6 +381,7 @@ static int parseargs(int argc, char *argv[]) {"debug", optional_argument, 0, 1003}, {"noprogressbar", no_argument, 0, 1004}, {"noscriptlet", no_argument, 0, 1005}, + {"gpgdir", required_argument, 0, 1006}, {"cachedir", required_argument, 0, 1007}, {"asdeps", no_argument, 0, 1008}, {"logfile", required_argument, 0, 1009}, @@ -446,6 +462,9 @@ static int parseargs(int argc, char *argv[]) case 1012: config->flags |= PM_TRANS_FLAG_ALLEXPLICIT; break; + case 1006: + config->gpgdir = strdup(optarg); + break; case 'Q': config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_QUERY); break; case 'R': config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_REMOVE); break; case 'S': config->op = (config->op != PM_OP_MAIN ? 0 : PM_OP_SYNC); break; @@ -725,6 +744,11 @@ static int _parseconfig(const char *file, const char *givensection, config->rootdir = strdup(ptr); pm_printf(PM_LOG_DEBUG, "config: rootdir: %s\n", ptr); } + } else if (strcmp(key, "GPGDir") == 0) { + if(!config->gpgdir) { + config->gpgdir = strdup(ptr); + pm_printf(PM_LOG_DEBUG, "config: gpgdir: %s\n", ptr); + } } else if (strcmp(key, "LogFile") == 0) { if(!config->logfile) { config->logfile = strdup(ptr); @@ -864,6 +888,7 @@ int main(int argc, char *argv[]) /* define paths to reasonable defaults */ alpm_option_set_root(ROOTDIR); alpm_option_set_dbpath(DBPATH); + alpm_option_set_signaturedir(GPGDIR); alpm_option_set_logfile(LOGFILE); /* Priority of options: -- 1.6.0.5
Am Sun, 14 Dec 2008 12:59:39 -0600 schrieb Chris Brannon <cmbrannon@cox.net>:
GnuPG looks for configuration files and keyrings in its home directory. For a user, that is typically ~/.gnupg. This patch causes pacman to use /etc/pacman.d/gnupg/ as the default GnuPG home. One may override the default using --gpgdir on the command-line or GPGDir in pacman's configuration file.
Seems to work here in test environment. I copied root's pubrig and trustdb to /etc/pacman.d/gnupg/ The package itself isn't checked (.sig file or signature), but that was not the reason of your patch. What i mentioned in another posting (that libalpm don't find the keyring dir) is gone with your patch. Regards Gerhard
On Mon, Dec 15, 2008 at 12:47 PM, Gerhard Brauer <gerbra@archlinux.de> wrote:
Am Sun, 14 Dec 2008 12:59:39 -0600 schrieb Chris Brannon <cmbrannon@cox.net>:
GnuPG looks for configuration files and keyrings in its home directory. For a user, that is typically ~/.gnupg. This patch causes pacman to use /etc/pacman.d/gnupg/ as the default GnuPG home. One may override the default using --gpgdir on the command-line or GPGDir in pacman's configuration file.
Seems to work here in test environment. I copied root's pubrig and trustdb to /etc/pacman.d/gnupg/ The package itself isn't checked (.sig file or signature), but that was not the reason of your patch.
What i mentioned in another posting (that libalpm don't find the keyring dir) is gone with your patch.
I like /etc/pacman.d/gnupg/ as the default dir. +1 from me 8)
Gerhard Brauer <gerbra@archlinux.de> writes:
Seems to work here in test environment. I copied root's pubrig and trustdb to /etc/pacman.d/gnupg/ The package itself isn't checked (.sig file or signature), but that was not the reason of your patch.
If the signing key is not found in your public keyring, then pacman will install the package without checking the signature. OTOH, if the signing key is available but not trusted and valid, pacman will refuse to install the signed package. Try removing trustdb from the gpg directory, while leaving pubring intact. You'll see what I mean. To summarize, it checks the signature if the key is found in pubring. I think pacman should at least complain if the signing key is not found in the public keyring. Thoughts? -- Chris
Am Mon, 15 Dec 2008 13:50:49 -0600 schrieb Chris Brannon <cmbrannon@cox.net>:
Try removing trustdb from the gpg directory, while leaving pubring intact. You'll see what I mean. To summarize, it checks the signature if the key is found in pubring.
Yes, you're right. Got this in debug when the key is not trusted (no trustdb): summary=0 fpr=0403BBB7C3907CDA95FBB3E61221825A96A08062 status=0 timestamp=1228738371 wrong_key_usage=0 pka_trust=0 chain_model=0 validity=0 validity_reason=0 key=17 hash=2 error: Package /var/cache/pacman/pkg/abook-0.5.6-4-i686.pkg.tar.gz has an invalid signature. abook-0.5.6-4-i686.pkg.tar.gz is invalid or corrupted And this when the signing pubkey is trusted: summary=3 fpr=0403BBB7C3907CDA95FBB3E61221825A96A08062 status=0 timestamp=1228738371 wrong_key_usage=0 pka_trust=0 chain_model=0 validity=4 validity_reason=0 key=17 hash=2 debug: installing packages debug: found cached pkg: /var/cache/pacman/pkg/abook-0.5.6-4-i686.pkg.tar.gz debug: loading target '/var/cache/pacman/pkg/abook-0.5.6-4-i686.pkg.tar.gz' debug: no package signature file found The last line confused me...
I think pacman should at least complain if the signing key is not found in the public keyring. Thoughts?
IMHO pacman should refuse to install anything from core and extra if the signature is not found or corrupted. I don't know what to to with community (maybe a second keyring with TU signatures?) My thoughts were to make a option to each repo section in pacman.conf. With this option: Keyring = /foo/bar we have an indicator that pacman should check for correct signatures and users could have their unsigned or self-signed repos additionally.
-- Chris
Regards Gerhard
On Mon, Dec 15, 2008 at 2:11 PM, Gerhard Brauer <gerbra@archlinux.de> wrote:
Am Mon, 15 Dec 2008 13:50:49 -0600 schrieb Chris Brannon <cmbrannon@cox.net>:
I think pacman should at least complain if the signing key is not found in the public keyring. Thoughts?
IMHO pacman should refuse to install anything from core and extra if the signature is not found or corrupted. I don't know what to to with community (maybe a second keyring with TU signatures?)
Pacman knows nothing about [core], [extra], and [community], so this will not be possible. However, I had considered a few possibilities for this type of stuff and this was the best I could think of: One shared keyring for all repos. Under each repository section, we would have a VerifySignatures option or something similar, which would take values of "Always", "Optional", or "Never", with one of these as a sane default. We would fail when set to "Always" if packages had no signature, we didn't have the signature on the package, or if the signature was invalid. For optional, we would verify the signature if it was there and we had it in our keychain; spit a warning otherwise but continue on. Never seems self explanatory
My thoughts were to make a option to each repo section in pacman.conf. With this option: Keyring = /foo/bar we have an indicator that pacman should check for correct signatures and users could have their unsigned or self-signed repos additionally.
Ha! We think alike. I actually typed the above before I read this. -Dan
A quick question...... I saw this in be_package.c pkg_load() /* look around for a PGP signature file; load if available */
MALLOC(pgpfile, strlen(pkgfile) + 5, RET_ERR(PM_ERR_MEMORY, NULL)); sprintf(pgpfile, "%s.sig", pkgfile); if(access(pgpfile, R_OK) == 0) { FILE *f; long bytes; f = fopen(pgpfile, "rb"); fseek(f, 0L, SEEK_END); bytes = ftell(f); fseek(f, 0L, SEEK_SET); /* don't read the file in if it is obviously not the size of a sig */ if(bytes == 72) { CALLOC(newpkg->pgpsig.rawdata, bytes, sizeof(char), RET_ERR(PM_ERR_MEMORY, NULL)); fread(newpkg->pgpsig.rawdata, sizeof(char), bytes, f); newpkg->pgpsig.rawlen = bytes; _alpm_log(PM_LOG_DEBUG, "loaded package .sig file, location %s\n", pgpfile); } else { _alpm_log(PM_LOG_WARNING, _("PGP signature file for %s was abnormal" " (had length %ld), skipping\n"), pkgfile, bytes); } fclose(f); } else { _alpm_log(PM_LOG_DEBUG, "no package signature file found\n"); } FREE(pgpfile);
So do we download the signature file along with the package? Or use %PGPSIG% in the db? On Tue, Dec 16, 2008 at 3:49 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Dec 15, 2008 at 2:11 PM, Gerhard Brauer <gerbra@archlinux.de> wrote:
Am Mon, 15 Dec 2008 13:50:49 -0600 schrieb Chris Brannon <cmbrannon@cox.net>:
I think pacman should at least complain if the signing key is not found in the public keyring. Thoughts?
IMHO pacman should refuse to install anything from core and extra if the signature is not found or corrupted. I don't know what to to with community (maybe a second keyring with TU signatures?)
Pacman knows nothing about [core], [extra], and [community], so this will not be possible. However, I had considered a few possibilities for this type of stuff and this was the best I could think of: One shared keyring for all repos. Under each repository section, we would have a VerifySignatures option or something similar, which would take values of "Always", "Optional", or "Never", with one of these as a sane default. We would fail when set to "Always" if packages had no signature, we didn't have the signature on the package, or if the signature was invalid. For optional, we would verify the signature if it was there and we had it in our keychain; spit a warning otherwise but continue on. Never seems self explanatory
My thoughts were to make a option to each repo section in pacman.conf. With this option: Keyring = /foo/bar we have an indicator that pacman should check for correct signatures and users could have their unsigned or self-signed repos additionally.
Ha! We think alike. I actually typed the above before I read this.
-Dan _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
A patch for adding VerifySignature options in pacman.conf
From cbe0f2ccf64509f6182136bbfa35ec934dd18d2d Mon Sep 17 00:00:00 2001 From: shankar <jatheendra@gmail.com> Date: Wed, 17 Dec 2008 16:25:07 +0530 Subject: [PATCH] Added gpg verification options per repo to the config file
--- lib/libalpm/alpm.h | 9 +++++++++ lib/libalpm/db.c | 31 +++++++++++++++++++++++++++++++ lib/libalpm/db.h | 2 ++ src/pacman/pacman.c | 18 ++++++++++++++++++ 4 files changed, 60 insertions(+), 0 deletions(-) diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index c26b8bb..fedfc12 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -249,6 +249,15 @@ typedef enum _pgpcheck_t { pgpcheck_t alpm_pkg_check_pgp_signature(pmpkg_t *pkg); +/* GPG signature verification option */ +typedef enum _pmdb_verify_gpg { + PM_GPG_VERIFY_ALWAYS, + PM_GPG_VERIFY_OPTIONAL, + PM_GPG_VERIFY_NEVER +} pmdb_verify_gpg; + + +int alpm_db_set_gpg_opt(pmdb_t *db, pmdb_verify_gpg verify); /* * Deltas */ diff --git a/lib/libalpm/db.c b/lib/libalpm/db.c index 9b91ce4..2bf03fb 100644 --- a/lib/libalpm/db.c +++ b/lib/libalpm/db.c @@ -206,6 +206,37 @@ int SYMEXPORT alpm_db_setserver(pmdb_t *db, const char *url) return(0); } +/** Set the verify gpg signature option for a database. + * @param db database pointer + * @param verify enum pmdb_verify_gpg + * @return 0 on success, -1 on error (pm_errno is set accordingly) + */ +int SYMEXPORT alpm_db_set_gpg_opt(pmdb_t *db, pmdb_verify_gpg verify) +{ + alpm_list_t *i; + int found = 0; + + ALPM_LOG_FUNC; + + /* Sanity checks */ + ASSERT(db != NULL, RET_ERR(PM_ERR_DB_NULL, -1)); + + for(i = handle->dbs_sync; i && !found; i = i->next) { + pmdb_t *sdb = i->data; + if(strcmp(db->treename, sdb->treename) == 0) { + found = 1; + } + } + if(!found) { + RET_ERR(PM_ERR_DB_NOT_FOUND, -1); + } + + db->verify_gpg = verify; + _alpm_log(PM_LOG_DEBUG, "adding VerifySig option to database '%s': %d\n", + db->treename, verify); + + return(0); +} /** Get the name of a package database * @param db pointer to the package database diff --git a/lib/libalpm/db.h b/lib/libalpm/db.h index 96fac0d..b94ef01 100644 --- a/lib/libalpm/db.h +++ b/lib/libalpm/db.h @@ -37,6 +37,7 @@ typedef enum _pmdbinfrq_t { INFRQ_ALL = 0x3F } pmdbinfrq_t; + /* Database */ struct __pmdb_t { char *path; @@ -45,6 +46,7 @@ struct __pmdb_t { alpm_list_t *pkgcache; alpm_list_t *grpcache; alpm_list_t *servers; + pmdb_verify_gpg verify_gpg; }; /* db.c, database general calls */ diff --git a/src/pacman/pacman.c b/src/pacman/pacman.c index 18fd3a8..0292cfa 100644 --- a/src/pacman/pacman.c +++ b/src/pacman/pacman.c @@ -788,6 +788,24 @@ static int _parseconfig(const char *file, const char *givensection, } free(server); + } else if(strcmp(key, "VerifySig") == 0) { + if (strcmp(ptr, "Always") == 0) { + ret = alpm_db_set_gpg_opt(db,PM_GPG_VERIFY_ALWAYS); + } else if (strcmp(ptr, "Optional") == 0) { + ret = alpm_db_set_gpg_opt(db,PM_GPG_VERIFY_OPTIONAL); + } else if (strcmp(ptr, "Never") == 0) { + ret = alpm_db_set_gpg_opt(db,PM_GPG_VERIFY_NEVER); + } else { + pm_printf(PM_LOG_ERROR, _("invalid value for 'VerifySig' : '%s'\n"), ptr); + ret = 1; + goto cleanup; + } + if ( ret != 0) { + pm_printf(PM_LOG_ERROR, _("could not add gpg verify option to database '%s': %s (%s)\n"), + alpm_db_get_name(db), ptr, alpm_strerrorlast()); + goto cleanup; + } + pm_printf(PM_LOG_DEBUG, "Verify GPG signature for %s: %s\n",alpm_db_get_name(db), ptr); } else { pm_printf(PM_LOG_ERROR, _("config file %s, line %d: directive '%s' not recognized.\n"), file, linenum, key); -- 1.6.0.4 On Tue, Dec 16, 2008 at 3:49 AM, Dan McGee <dpmcgee@gmail.com> wrote:
On Mon, Dec 15, 2008 at 2:11 PM, Gerhard Brauer <gerbra@archlinux.de> wrote:
Am Mon, 15 Dec 2008 13:50:49 -0600 schrieb Chris Brannon <cmbrannon@cox.net>:
I think pacman should at least complain if the signing key is not found in the public keyring. Thoughts?
IMHO pacman should refuse to install anything from core and extra if the signature is not found or corrupted. I don't know what to to with community (maybe a second keyring with TU signatures?)
Pacman knows nothing about [core], [extra], and [community], so this will not be possible. However, I had considered a few possibilities for this type of stuff and this was the best I could think of: One shared keyring for all repos. Under each repository section, we would have a VerifySignatures option or something similar, which would take values of "Always", "Optional", or "Never", with one of these as a sane default. We would fail when set to "Always" if packages had no signature, we didn't have the signature on the package, or if the signature was invalid. For optional, we would verify the signature if it was there and we had it in our keychain; spit a warning otherwise but continue on. Never seems self explanatory
My thoughts were to make a option to each repo section in pacman.conf. With this option: Keyring = /foo/bar we have an indicator that pacman should check for correct signatures and users could have their unsigned or self-signed repos additionally.
Ha! We think alike. I actually typed the above before I read this.
-Dan _______________________________________________ pacman-dev mailing list pacman-dev@archlinux.org http://archlinux.org/mailman/listinfo/pacman-dev
Am Wed, 17 Dec 2008 18:22:36 +0530 schrieb Jatheendra <jatheendra@gmail.com>:
A patch for adding VerifySignature options in pacman.conf
From your other mail: ------------ These patches will add VerifySig option to pacman.conf. VerifySig takes options Always, Optional or Never [repo-name] Server = ServerName VerifySig = Always Include = IncludePath ------------ I've not tested your patch (today evening maybe), but i am not very happy with this triple state. If i choose to use a repo which offers signed packages then i want the "full program", so if something wrong with one package i don't want it get installed/upgraded. And if i have a repo without signing then i don't put the option in the repo section of pacman.conf. I found my suggestion has mor advantages, ex.: ------------ [core] Keyring = /etc/pacman.d/gpg/devel.gpg ... [community] Keyring = /etc/pacman.d/gpg/community.gpg ... [myrepo] ... [yaourt] Keyring = /etc/pacman.d/gpg/fr-repo.gpg ... ------------ a) The Keyring= Option indicates pacman if the signing framework should be used b) This var signals pacman where to find the public keyring for this repo. AND we could have different keyrings for repos. Ex.: the TU (if community packages get signed) fluctuation is IMHO bigger than on the Developers side. So keyring updates are more often necassary on community/TU side. And myself find it better to have the TUs signatures/trustlevel not in the same keyring like developers (core,extra) keyring for package signing. c) With this var a extern repo (ex. the france yaourt repo) could offers also signed packages - and a properly public keyring. I think a little further (currently in the phase were we not finished with programming to maybe avoid false paradigms): - How get the users the keyrings, how get they updated? - How is the trustdb(Trustlevel) handled? Must/should each user first sign each public key in the keyrings (Urghhh!)? Or is it better to deliver both signing framework files for a repo (ex. core): devel.gpg (=the keyring with public keys) and develdb-gpg (=the trustdb file). This trustdb file could could be the arch-web-of-trust where the arch leader for .ex. signes all devel keys, so they are trusted for this keyring pair.
Am Thu, 18 Dec 2008 14:02:48 +0100 schrieb Gerhard Brauer <gerbra@archlinux.de>: Sorry, bad key stroke send this mail before finished...
trusted for this keyring pair.
Last sentence: If we - you developers ;-) - discuss this early enough then the necessary code changes could be smarter... Regards Gerhard
Gerhard Brauer <gerbra@archlinux.de> writes:
a) The Keyring= Option indicates pacman if the signing framework should be used
b) This var signals pacman where to find the public keyring for this repo. AND we could have different keyrings for repos. Ex.: the TU (if community packages get signed) fluctuation is IMHO bigger than on the Developers side. So keyring updates are more often necassary on community/TU side. And myself find it better to have the TUs signatures/trustlevel not in the same keyring like developers (core,extra) keyring for package signing.
c) With this var a extern repo (ex. the france yaourt repo) could offers also signed packages - and a properly public keyring.
If I understand gpgme correctly, you can't just tell it to use a public keyring from a given file. This applies to the gpg binary as well. GnuPG's paradigm is one of home directories. You specify a GnuPG home directory, such as ~/.gnupg or /etc/pacman.d/gnupg, and it looks for pubring.gpg and other necessary files in that place. One possibility is to allow overriding of GPGDir on a per-repo basis. Regards, -- Chris
Am Thu, 18 Dec 2008 07:36:06 -0600 schrieb Chris Brannon <cmbrannon@cox.net>:
Gerhard Brauer <gerbra@archlinux.de> writes:
c) With this var a extern repo (ex. the france yaourt repo) could offers also signed packages - and a properly public keyring.
If I understand gpgme correctly, you can't just tell it to use a public keyring from a given file. This applies to the gpg binary as well.
Hmm, gpg manpage list the options: --trustdb-name file and --keyring file and fore general place the --homedir dir option. gpgme have not a similar function or any possibility to use/set these?
One possibility is to allow overriding of GPGDir on a per-repo basis.
Regards, -- Chris
Gerhard
On Thu, Dec 18, 2008 at 7:02 AM, Gerhard Brauer <gerbra@archlinux.de> wrote:
Am Wed, 17 Dec 2008 18:22:36 +0530 schrieb Jatheendra <jatheendra@gmail.com>:
A patch for adding VerifySignature options in pacman.conf
From your other mail:
These patches will add VerifySig option to pacman.conf. VerifySig takes options Always, Optional or Never
[repo-name] Server = ServerName VerifySig = Always Include = IncludePath ------------
I've not tested your patch (today evening maybe), but i am not very happy with this triple state. If i choose to use a repo which offers signed packages then i want the "full program", so if something wrong with one package i don't want it get installed/upgraded. And if i have a repo without signing then i don't put the option in the repo section of pacman.conf.
I think "Optional" makes sense in some cases. Let's take the community repo, where things tend to be a hodge-podge of ideas and attitudes. I can imagine half the packages being signed, some being unsigned, and some being signed by keys not in the keyring. That is an edge case though...
Am Donnerstag 18 Dezember 2008 17:22:25 schrieb Aaron Griffin:
I think "Optional" makes sense in some cases. Let's take the community repo, where things tend to be a hodge-podge of ideas and attitudes. I can imagine half the packages being signed, some being unsigned, and some being signed by keys not in the keyring.
Well, if that will be the case we can forget about the whole signing stuff. One "unprotected" package is enough to inject your custom code. -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
On Thu, Dec 18, 2008 at 10:42 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
Am Donnerstag 18 Dezember 2008 17:22:25 schrieb Aaron Griffin:
I think "Optional" makes sense in some cases. Let's take the community repo, where things tend to be a hodge-podge of ideas and attitudes. I can imagine half the packages being signed, some being unsigned, and some being signed by keys not in the keyring.
Well, if that will be the case we can forget about the whole signing stuff. One "unprotected" package is enough to inject your custom code.
Right, but that's not what I'm saying. As a user, I might not care. Actually, I don't. Here's our cases: People who care about super-secure packages: Set things to "Always" and then your system will only install signed packages Middle of the road people: Set core and extra to "Always" and other repos to either "Never" or "Optional". People who don't care: Everything is set to "Never". See, I fall in the middle case. I'd love to have everything signed, but I know it won't happen for everything all the time. So, if I set community to "Always", I'm going to run into a case where I want to install a package from community that is unsigned. We need a "fuck it, install it anyway" case. Now, instead of the "Optional" setting, if there was a --skip-signature flag that I could use, I would also be sated. Either way, I'd just like to see a case where I can force it to skip the signature check.
Am Donnerstag 18 Dezember 2008 18:01:52 schrieb Aaron Griffin:
Right, but that's not what I'm saying. As a user, I might not care. Actually, I don't. Here's our cases:
OK, I got the point. I think we should forget about what I have said. From pacman's point of view those options might make sense. When we really start using this we should discuss about our sigingn policy (meaning if we accept unsigned packages or not) -- Pierre Schmitz Clemens-August-Straße 76 53115 Bonn Telefon 0228 9716608 Mobil 0160 95269831 Jabber pierre@jabber.archlinux.de WWW http://www.archlinux.de
Am Thu, 18 Dec 2008 10:22:25 -0600 schrieb "Aaron Griffin" <aaronmgriffin@gmail.com>:
On Thu, Dec 18, 2008 at 7:02 AM, Gerhard Brauer <gerbra@archlinux.de> wrote:
I've not tested your patch (today evening maybe), but i am not very happy with this triple state. If i choose to use a repo which offers signed packages then i want the "full program", so if something wrong with one package i don't want it get installed/upgraded. And if i have a repo without signing then i don't put the option in the repo section of pacman.conf.
I think "Optional" makes sense in some cases. Let's take the community repo, where things tend to be a hodge-podge of ideas and attitudes. I can imagine half the packages being signed, some being unsigned, and some being signed by keys not in the keyring.
If we wan't this (or if the [community] situation lead us to MUST wan't this) then such a "Optional" is ok IMHO (with a pacman warning...) But the question (also the TU's must discuss this) is: why not also sign community packages per policy? - The build tools (where signing is integrated) are both the same for developers and TUs. - Also the TU's have the same interest like the devs that their packages are on good integrity when they leaves their machines and that this could be checked before the users installed these. (we make this signing thing not for funny ;-) - Only TU's(and Devs) putting packages in community, so the count of needed keys is not soo much. But TUs come and go more often than Devs, so a separate keyring makes sense IMHO cause it changes often. So if we find a solution to avoid this "Optional" setting, that would be better IMHO. (To clear: I'm neither a Dev nor a TU (and badly also not a C programmer...), my suggestions comes most from the "user side" of this theme... But i like always to say: "We" <g>) Regards Gerhard
participants (6)
-
Aaron Griffin
-
Chris Brannon
-
Dan McGee
-
Gerhard Brauer
-
Jatheendra
-
Pierre Schmitz