On Sun 2017-09-17 16:26:25 -0700, Russ Allbery wrote:
> I personally lean towards 2, which is consistent with what's in Policy
> right now, but I can see definite merits in 3. I believe the reproducible
> builds project is currently sort of doing 1, but I have a hard time seeing
> how to make
On Fri 2017-08-18 14:43:58 +0200, Mattia Rizzolo wrote:
> I'd love if something did this for me, pretty much like I'd love
> something like that does a pretty output to debian/upstream/signing-key
> like
> https://sources.debian.net/src/inkscape/0.92.2-1/debian/upstream/signing-key.asc/
On Fri 2017-08-18 12:08:02 +0200, Guillem Jover wrote:
> Hmmm, I've been thinking about this a bit, and perhaps it would be
> better if dpkg-source auto-converted any .sig binary signature into
> an .asc ASCII armored one when generating the source package (as long
> as there is no pre-existing
Thanks for the proposal. I like it! A few nit-picks below:
On Fri 2017-08-11 16:08:47 -0700, Sean Whitton wrote:
> - a version of a source package unpacked at a given path;
I don't like the idea of hard-coding a fixed build path requirement into
debian policy. We're over 80% with
On Mon 2017-08-07 09:40:22 -0700, Russ Allbery wrote:
> In an ideal world, we would have a documented set of metadata for finding
> upstream releases, of which uscan is just one implementation, and document
> that in Policy.
In an ideal world, uscan would be able to verify signed git tags and
Package: developers-reference
Version: 3.4.18
Severity: normal
Control: tags -1 patch
Control: affects -1 devscripts
Please do not mention debrsign in the developers-reference. The
workflow encouraged by debrsign is less secure than the one we'd like
to recommend for developers (it involves the
Control: clone 732445 -2
Control: reassign -2 developers-reference
Control: retitle -2 developers-reference should encourage verification of
upstream cryptographic signatures
Control: retitle 732445 debian-policy should encourage verification of upstream
cryptographic signatures
Hi Bill--
On
On 03/24/2014 07:51 PM, Russ Allbery wrote:
I'm curious -- why do we have two different supported paths? At least in
my experience the ASCII-armored key is much easier to deal with, since you
don't have to configure dpkg to allow binary files in the debian
directory. I'm not sure that I see
On 05/30/2012 07:34 PM, Ben Hutchings wrote:
Since we don't seem to have a specific directory for server
certificates, I suppose it should be under /etc/dovecot.
If anyone following this bug report is coming to debconf12, i've
submitted a BoF proposal to try to get together and hammer out some
On 04/09/2012 10:35 AM, Kurt Roeckx wrote:
On Mon, Apr 09, 2012 at 09:52:44AM -0400, Daniel Kahn Gillmor wrote:
On 04/07/2012 12:46 PM, Kurt Roeckx wrote:
At least the certdata.txt file contains the information, you can
edit in iceweasel/firefox.
edit at runtime or at compile time? system
On 04/02/2012 12:48 PM, Russ Allbery wrote:
Bill Allombert bill.allomb...@math.u-bordeaux1.fr writes:
Another issue is that no directories is provided for the system
administrator to put their local certs. Of course they can use
/etc/ssl/certs, but then the certs are drowned by the number.
On 04/02/2012 03:54 PM, Russ Allbery wrote:
You definitely want class 0 and class 2 certs hashed into the same
directory under nearly all circumstances that don't involve being very
paranoid about the CAs that you accept, since that allows the OpenSSL
CAdir directive to work properly and is
[this discussion started on http://bugs.debian.org/608719]
On 03/19/2012 11:14 PM, Ben Hutchings wrote:
On Sun, 2011-01-02 at 18:20 -0500, Daniel Kahn Gillmor wrote:
It looks like dovecot-common's postinst script creates a new X.509
certificate and places it in /etc/ssl/certs/dovecot.pem
Package: debian-policy
Version: 3.7.3.0
Severity: normal
Tags: patch
The scripts section of chapter 10 is somewhat ambiguous about
whether declaring multiple local variables is acceptable or not:
file:///usr/share/doc/debian-policy/policy.html/ch-files.html#s-scripts
For example, is the
Thanks for the quick response, Russ.
On Thu 2008-03-27 16:16:31 -0400, Russ Allbery wrote:
The intention when I originally wrote the text was to not allow declaring
multiple variables with one local line, since at the time I was told that
some shells didn't support this.
I think your first
15 matches
Mail list logo
