FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 07-18-2011, 06:35 AM
Kerrick Staley
 
Default Document new SigLevel config directive

The SigLevel config option replaces the VerifySig option, and has
similar semantics, but adds a set of advanced configuration options that
correspond to the recently introduced alpm_siglevel_t fields.

Signed-off-by: Kerrick Staley <mail@kerrickstaley.com>
---
doc/pacman.conf.5.txt | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/doc/pacman.conf.5.txt b/doc/pacman.conf.5.txt
index a28e00f..19cd6e3 100644
--- a/doc/pacman.conf.5.txt
+++ b/doc/pacman.conf.5.txt
@@ -156,6 +156,26 @@ Options
packages are only cleaned if not installed locally and not present in any
known sync database.

+*SigLevel =* ...::
+ If set to `Optional` (the default), signatures will be checked if present,
+ but unsigned databases/packages will also be allowed. Setting to `Required`
+ will cause signatures to be required on all packages and databases. `Never`
+ will prevent all signature checking.
+ Alternatively, you get more fine-grained control by combining some of
+ the options described below.
+ `PackageRequired` works like `Required`, but only causes checks to
+ be performed on packages. `PackageOptional` works like `Optional`
+ but also for packages only, and it can't be specified along with
+ `PackageRequired`. `PackageMarginal` causes signatures from marginally
+ trusted keys to be accepted on packages. `PackageUnknown` causes
+ signatures made with an unknown key to be accepted on packages. All
+ of these `PackageX` options have corresponding `DatabaseX`
+ options. Lastly, `PackageHash` causes a secure hash in a database to
+ be accepted as a package signature. It probably should be combined with
+ `DatabaseRequired`. This `PackageHash`+`DatabaseRequired` combination is
+ reasonably secure and is a good compromise when signing every package is
+ too difficult for a distribution's maintainers.
+
*UseSyslog*::
Log action messages through syslog(). This will insert log entries into
+{localstatedir}/log/messages+ or equivalent.
--
1.7.6
 
Old 07-18-2011, 07:58 AM
Allan McRae
 
Default Document new SigLevel config directive

On 18/07/11 16:35, Kerrick Staley wrote:

The SigLevel config option replaces the VerifySig option, and has
similar semantics, but adds a set of advanced configuration options that
correspond to the recently introduced alpm_siglevel_t fields.

Signed-off-by: Kerrick Staley<mail@kerrickstaley.com>
---
doc/pacman.conf.5.txt | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/doc/pacman.conf.5.txt b/doc/pacman.conf.5.txt
index a28e00f..19cd6e3 100644
--- a/doc/pacman.conf.5.txt
+++ b/doc/pacman.conf.5.txt
@@ -156,6 +156,26 @@ Options
packages are only cleaned if not installed locally and not present in any
known sync database.

+*SigLevel =* ...::


I was fairly sure previous the discussion indicated we would go with
CheckLevel for the name of this.


Anyway, I think it would be good to get a complete list of options
sorted before documenting and implementing... Currently it seems
incomplete.


Global options:
Required (or Always?), Optional, Never - what about global controls for
allowing marginal and unknown signatures.


Also, we need to determine exactly how the suboptions will work. Do the
PackageFoo options override global options? E.g. are these all
equivalent (require database signatures but not package signatures)?


CheckLevel = Required PackageOptional
CheckLevel = Optional DatabaseRequired
CheckLevel = DatabaseRequired PackageOptional

Allan
 
Old 07-18-2011, 09:06 AM
Kerrick Staley
 
Default Document new SigLevel config directive

Required, Optional, and Never aren't to be mixed with the other settings.
The original version said this, but I thought the whole thing was getting
long winded, so I reworded it in a way that I thought would make this
implicit (guess not .

Required, Optional, and Never will be sufficient for like 90% of users
(which is probably why they were the only options until recently), so I
separated them out from the more "advanced" settings (many people won't [and
shouldn't have to] know what e.g. marginally trusted signatures are).

-Kerrick Staley
On Jul 18, 2011 2:55 AM, "Allan McRae" <allan@archlinux.org> wrote:
> On 18/07/11 16:35, Kerrick Staley wrote:
>> The SigLevel config option replaces the VerifySig option, and has
>> similar semantics, but adds a set of advanced configuration options that
>> correspond to the recently introduced alpm_siglevel_t fields.
>>
>> Signed-off-by: Kerrick Staley<mail@kerrickstaley.com>
>> ---
>> doc/pacman.conf.5.txt | 20 ++++++++++++++++++++
>> 1 files changed, 20 insertions(+), 0 deletions(-)
>>
>> diff --git a/doc/pacman.conf.5.txt b/doc/pacman.conf.5.txt
>> index a28e00f..19cd6e3 100644
>> --- a/doc/pacman.conf.5.txt
>> +++ b/doc/pacman.conf.5.txt
>> @@ -156,6 +156,26 @@ Options
>> packages are only cleaned if not installed locally and not present in any
>> known sync database.
>>
>> +*SigLevel =* ...::
>
> I was fairly sure previous the discussion indicated we would go with
> CheckLevel for the name of this.
>
> Anyway, I think it would be good to get a complete list of options
> sorted before documenting and implementing... Currently it seems
> incomplete.
>
> Global options:
> Required (or Always?), Optional, Never - what about global controls for
> allowing marginal and unknown signatures.
>
> Also, we need to determine exactly how the suboptions will work. Do the
> PackageFoo options override global options? E.g. are these all
> equivalent (require database signatures but not package signatures)?
>
> CheckLevel = Required PackageOptional
> CheckLevel = Optional DatabaseRequired
> CheckLevel = DatabaseRequired PackageOptional
>
> Allan
>
 

Thread Tools




All times are GMT. The time now is 10:13 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org