Bug#876055: Environment variable handling for reproducible builds
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 that viable on the testing side. Thanks for raising this question, Russ! I'm not sure that we should let lack of exhaustive testing push us away from (1). (1) is in principle the right thing -- it's easy to make a build reproducible if we tell people that they have to do exactly one specific thing. But we generally want people to be able to run heterogenous systems, and not to force them into one particular environment. Consider someone who wants to see more logging from a build, for example. There could be an environment variable that encourages the toolchain to log more, but doesn't affect the binary objects created by the build. By going with choices (2) or (3) we effectively dismiss even considering the reproducibility of those builds, which seems like a shame. Does everything in policy need to be rigorously testable? or is it ok to have Policy state the desired outcome even if we don't know how (or don't have the resources) to test it fully today. I'd prefer for policy to be able to make strong advisory statements even without us being able to test them mechanically. This is already the case for (for example) "preferred form of modification" -- it's partly testable, but will never be 100% testable, and will always require research and discussion and thinking for the corner cases. Yet we continue to aim for it. Policy should be aiming high, not lowering the bar to meet what's concretely testable. --dkg
Re: Upstream Tarball Signature Files
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/ Interesting! I worry about that, though, because the human-readable header can go out-of-sync with the underlying b64-encoded data. I think what we really need is an easier way to easily view an OpenPGP certificate, in the same way that we might prefer to view a PNG with a graphical viewer instead of hexdump ;) --dkg
Re: Upstream Tarball Signature Files
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 .asc file). This has the advantage of not > requiring devscripts to be installed, preserves compatibility with > stable dpkg-source and DAK so it can be used right away, and allows > us to keep using a single signature format. I've got code doing that > now, which I can merged for 1.19.0, I guess the only possibly > contentious point is that this might seem like doing too much magic > from within dpkg-source? > > If people are comfortable with this, I'm happy to merge it. I've got no objection to this. I confess that i've been taking the boring/silly/cheating way out and if upstream ships a detached binary signature as foo-1.2.3.tar.gz.sig, i've just been manually renaming it to foo_1.2.3.orig.tar.gz.asc (without even converting its contents to ASCII-armored form) and the rest of the toolchain seems to just happily accept it -- it'd be even nicer if dpkg and/or uscan was to normalize the contents to match the file extension. Note that it's possible that something named .sig is itself already armored, though, we don't want to double-armor it. Lastly, it's conceivable that we might want to take an already-armored .asc, and "launder" the armor, to stabilize it (e.g. stripping non-cryptographically-relevant comments, other weird OpenPGP packets, etc, which could all be stuffed into the detached signature). I am not proposing this as a requirement, and i don't want the suggestion to block the .sig→.asc fix, but if thinking about that part of the code, it might be easy to do at the time. Doing so would reduce the amount of non-cryptographically-justified sidechannels that debian is willing to cart around on behalf of upstream authors. (of course, we're currently willing to cart stuff around for upstream authors who don't make cryptographic signatures at all today, so maybe it's too nit-picky to obsess about sidechannels just for those who make signatures) Thanks for working on this, Guillem! --dkg signature.asc Description: PGP signature
Bug#844431: Reproducibility in Policy
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 variable build paths in unstable already, and i want to keep the pressure up on this. The build location should not influence the binary output. > repeatedly building the source package on the architecture with maybe s/on the architecture/on any machine of the same architecture/ ? all the best, --dkg
Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse
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
include the diff between the orig.tar.gz and a shallow clone of the git
repo as a patch to allow verification without history ;)
> This patch doesn't attempt to do that; it tries to find a compromise
> between the current Policy language ("include a watch file for uscan")
> and specifying the location of the upstream signing keys, while
> deferring all of the details to the uscan documentation.
i think this is a sensible approach. thanks for working on it, Russ.
> +If the upstream maintainer of the software provides PGP signatures
This should probably be s/PGP/OpenPGP/
all the rest looks good to me. I'm also happy to second it, if needed.
--dkg
signature.asc
Description: PGP signature
Bug#855320: developers-reference: Please do not recommend debrsign
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 untrusted machine having ssh access to the trusted machine), so we should be trying to phase it out. Please also see discussion at https://bugs.debian.org/855282 Regards, --dkg -- System Information: Debian Release: 9.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) developers-reference depends on no packages. Versions of packages developers-reference recommends: ii debian-policy 3.9.8.0 Versions of packages developers-reference suggests: ii doc-base 0.10.7 -- no debconf information
Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse
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 Sat 2014-03-22 12:19:52 -0400, Bill Allombert wrote: While I agree that verification of upstream cryptographic signatures is important, your patch mostly documents a tool to perform this task, which is not something which belongs to policy in general. Also policy is supposed to document commong practices, so it might be a bit too soon to document debian/upstream-signing-key.pgp. You're quite right about my original bug report having been premature and over-specific for debian-policy; sorry about that. The current preferred location is now debian/upstream/signing-key.pgp (binary form) or debian/upstream/signing-key.asc (ascii-armored). And i agree with you that the specifics of how it's done might not need to be in policy. However, as a matter of policy debian really should explicitly encourage developers to check whatever cryptographic verifications are offered by upstream, via whatever methods are available. And the use of debian/upstream/signing-key.* is becoming more common: http://codesearch.debian.net/search?q=signing-key.pgp shows over 370 hits, probably at least a hundred packages, including important packages like apache2 and openssh and libgcrypt11. So i'm leaving the policy bug open because i think it's worth mentioning the suggestion. This is useful for both debian and our upstreams. So i'm leaving this bug open with a plea for simpler/more generic text that encourages developers to do cryptographic verification, but i'm not sure what section of policy that should be in, if it's not concretely tied to debian/watch the way this specific patch was. any suggestions? i'm happy to write a couple sentences if someone wants to point me at the right section or subsection for context. Maybe at this stage, the recommendation would be better placed in developers-reference. thanks, that's a good idea. i've cloned the bug to suggest its inclusion in developers-reference, where the specific and concrete language is probably more appropriate. --dkg pgpY74EQa76uP.pgp Description: PGP signature
Bug#732445: debian-policy should encourage verification of upstream cryptographic signaturse
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 any drawback to just saying to always use the *.asc form. we actually have three supported paths at the moment: debian/upstream-signing-key.pgp debian/upstream/signing-key.pgp debian/upstream/signing-key.asc the first was my first implementation of this mechanism. the binary form is easiest to use directly with gpgv, which was the only additional dependency. Later, James McCoy moved the file to debian/upstream/ (which i didn't know existed when i made the original implementation) and added code to support the *.asc version. the *.asc version can only be checked if gnupg is available, apparently (though it should be easy enough to just use perl's MIME::Base64 to convert if we wanted to drop the gnupg dependency and just leave it depending on gpgv) I'd be happy to see us settle on one single location, and if folks think that the .asc version is the better option, updating lintian to nag about the other ones until they go away seems doable before we freeze for jessie. I'll even file patches or do NMUs for packages that need them if a lintian tag appears. Thinking further, I wonder if we should also encourage packagers to store the detached signature itself in the packaging directly (e.g. maybe in debian/upstream/signature.asc), so that the upstream tarball can be re-verified against the signing key even if the upstream archive goes offline; maybe that's a separate issue. Another comment based on my personal experience with this is that, if the packager is generating this key by exporting a key from a keyring (for example, for the packages for which I'm also upstream, I'm exporting my own key), they should do so with --export-options export-minimal. It makes the file *much* smaller, and I don't think there's any need to include all of the key signatures. The mere presence of this key in the (signed) Debian source package already indicates the trust relationship that's relevant for this purpose, and the end user can always retrieve additional key signatures from a public keyserver if they really want them. Yes, i do the same thing, and I agree with your security analysis of the reasons for having (or not having) any OpenPGP certifications on the upstream signing key(s) beyond the self-sigs. That said, if a debian packager wants to include extra OpenPGP certifications of moderate length, i don't think we should forbid them from doing so (i can imagine a packager wanting to include their own certification if they have made one, for example). I use: gpg --export --armor --export-options export-minimal key \ debian/upstream/signing-key.asc i think that's good advice, though i don't know whether it belongs in debian-policy or developers-reference. --dkg signature.asc Description: OpenPGP digital signature
Re: Bug#608719: Debian Policy about administrator X.509 certificate stores [was: Re: dovecot-common: please do not use /etc/ssl/certs for end-entity X.509 certificates (/etc/ssl/certs/dovecot.pem)]
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 best practices we can document for today (and hopefully shift into policy for wheezy+1 or thereabouts). --dkg signature.asc Description: OpenPGP digital signature
Re: Debian Policy about administrator X.509 certificate stores [was: Re: dovecot-common: please do not use /etc/ssl/certs for end-entity X.509 certificates (/etc/ssl/certs/dovecot.pem)]
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 administrators ideally shouldn't have to recompile packages in order to add or drop system-wide default reliance on a given CA. iceweasel/firefox allows editing it at runtime, just like it allows you to add more keys to it's store. I thnk it's stored in cert8.db / cert_override.txt. But that's all per application / user. Right, so this is not system-wide defaults, so it doesn't satisfy the need described above. Can you propose a mechanism such that this info would not get lost? X509 has a way to embed the trust in the certificate itself, see TRUST SETTINGS in openssl's x509 manpage. This looks like it only works with PEM output, and it appends chunks of (base64-encoded) ASN.1 data after the initial base64-encoded ASN.1 blob of the certificate. The header and footer of the PEM output changes from -BEGIN CERTIFICATE- to -BEGIN TRUSTED CERTIFICATE- which makes it so the certificate apparently can't be read by NSS's certutil. A cursory search doesn't turn up any sort of spec for -BEGIN TRUSTED CERTIFICATE- ; do you know if that's documented somewhere? --dkg signature.asc Description: OpenPGP digital signature
Re: Debian Policy about administrator X.509 certificate stores
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. ca-certificates supports putting local certificates into /usr/local/share/ca-certificates, after which they're treated as trusted certificates and linked into /etc/ssl/certs similar to how the certificates in /usr/share/ca-certificates are handled. There are (at least) two classes of local certs -- this is the core of all of this confusion. 0) there are certificate authority certs that the admin wants to rely on for certification. 1) there are certs used to identify TLS-capable services on the machine 2) (additionally, there are potentially intermediate certificates that chain back from the certs in class 1 -- these are needed for regular operation if certs in class 1 was not issued directly by a root authority). The ca-certificates package suggests /usr/local/share/ca-certificates/ as the correct place for certs in class 0. Secret keys (not certs) for TLS-capable services are usually suggested to be placed in /etc/ssl/private. But (AFAIK) there aren't any well-documented/clear/commonly-held standards for where certs in classes 1 and 2 should be placed. I think it would ease administration (and make it easier for various debian-knowledgable admins to help each other) if there was such a standard. --dkg signature.asc Description: OpenPGP digital signature
Re: Debian Policy about administrator X.509 certificate stores
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 WAY easier to maintain. I'm not convinced that you want class 2 mixed with class 0 in most cases. Class 2 certs are used for authentication of your own services; A web server might authenticate clients via your organization's private CA, for example, while serving your own certificate that is certified by a member of the standard cartel to avoid errors in common browsers. In this case, mixing class 0 and class 2 would be a serious mistake (because the web server would then accept client certificates issued by the public authority). It is often nice to have class 1 certs in the same location for the same reason, although not quite as important. Class 1 certs almost certainly do not belong in this category, since they are generally not intended for use as a certificate authority. The X.509 conceptual framework is pretty confusing already, and encouraging admins to conflate service certificates with CA certificates. It seems like a bad idea to me to mix them. Consider also the case of the depleted OpenSSL PRNG seed from 2008 -- if the local machine's key was one of the vulnerable ones, and it was trusted as a legitimate authority by being placed in this list, then both sides of a mutually-authenticated connection could be MITMed. --dkg signature.asc Description: OpenPGP digital signature
Debian Policy about administrator X.509 certificate stores [was: Re: dovecot-common: please do not use /etc/ssl/certs for end-entity X.509 certificates (/etc/ssl/certs/dovecot.pem)]
[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. This certificate is for use as the IMAP or POP server's end entity certificate. However, /etc/ssl/certs/ is used elsewhere in debian (e.g. the default for wget's --ca-directory option) as a directory of legitimate root certificate authorities -- *not* end entity certificates. Is this specified in any policy? If not, shouldn't it be discussed on debian-policy? Sure, that makes sense. I'm cc'ing debian-policy here. I'm not subscribed to that list, so please keep me Cc'ed in the followup. Personally, I think that it is a bad idea to treat the certificates in /etc/ssl/certs as automatically trusted. Even if packagers follow such a policy, system administrators likely will not read the policy and will not suspect that installing a certificate there has this effect. If this is the consensus within the project, perhaps a bug should be filed against the ca-certificates package then, since /usr/share/doc/ca-certificates/README.Debian states: “update-ca-certificates” will then update “/etc/ssl/certs” which may be used by the web browsers in Debian. It will also generate the hash symlinks and generate a single-file version in “/etc/ssl/certs/ca-certificates.crt”. and update-ca-certificates is run during postinst configure of the ca-certificates package. It seems to be me that it would be better to create subdirectories for different categories of certificates, e.g. 'trusted-ca', 'server', 'client'. Doing this kind of overhaul might be worthwhile, but i would break down the trusted-ca category still further. Consider, for example, that libNSS allows the user to identify which root CAs are trusted to: * identify web sites, * identify e-mail users, or * sign code (some CAs may trusted for all three categories, some for only one or two of them). If the system store could identify these separate categories differently, then we could divert (or ship a modified) libnssckbi.so that actually drew its configuration from the admin's configuration choices (instead of using the hardcoded builtins). Is there any existing debian policy about X.509 certificates we should be pursuing? What should the system administrator expect of /etc/ssl/certs? Would more documentation someplace help? --dkg -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f681415.90...@fifthhorseman.net
Bug#473019: debian-policy: clarification needed for local builtin exception for /bin/sh
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 following function compliant with policy in a
/bin/sh script? The arguments to local are no more complex than
simple variables:
func () {
local a b
a=foo
b=bar
# ...
}
Two patches below describe the more conservative interpretation (that
only a single variable may be locally scoped in policy-compliant
/bin/sh scripts), and the more liberal interpretation (multiple
variables can be listed in a single local declaration). Obviously,
only one of these should be applied!
Thanks for maintaining debian policy,
--dkg
[0 [EMAIL PROTECTED] debian-policy-3.7.3.0]$ diff -u policy.sgml{,.conservative}
--- policy.sgml 2008-03-27 14:52:16.0 -0400
+++ policy.sgml.conservative2008-03-27 14:55:37.0 -0400
@@ -6793,11 +6793,11 @@
itemtttest/tt, if implemented as a shell built-in, must
support tt-a/tt and tt-o/tt as binary logical
operators./item
- itemttlocal/tt to create a scoped variable must be
- supported; however, ttlocal/tt may or may not preserve
- the variable value from an outer scope and may or may not
- support arguments more complex than simple variables. Only
- uses such as:
+ itemttlocal/tt to create a single scoped variable
+ must be supported; however, ttlocal/tt may or may
+ not preserve the variable value from an outer scope and
+ may or may not support arguments more complex than a
+ single simple variable. Only uses such as:
example compact
fname () {
local a
[1 [EMAIL PROTECTED] debian-policy-3.7.3.0]$ diff -u policy.sgml{,.liberal}
--- policy.sgml 2008-03-27 14:52:16.0 -0400
+++ policy.sgml.liberal 2008-03-27 15:20:58.0 -0400
@@ -6793,11 +6793,11 @@
itemtttest/tt, if implemented as a shell built-in, must
support tt-a/tt and tt-o/tt as binary logical
operators./item
- itemttlocal/tt to create a scoped variable must be
- supported; however, ttlocal/tt may or may not preserve
- the variable value from an outer scope and may or may not
- support arguments more complex than simple variables. Only
- uses such as:
+ itemttlocal/tt to create scoped variables must be
+ supported; however, ttlocal/tt may or may not
+ preserve the variables' values from outer scopes and may
+ or may not support arguments more complex than a series
+ of simple variable names. Only uses such as:
example compact
fname () {
local a
[1 [EMAIL PROTECTED] debian-policy-3.7.3.0]$
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (101, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#473019: debian-policy: clarification needed for local builtin exception for /bin/sh
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 patch is therefore correct and intend to apply it
unless someone tells me that my understanding of shellology is incorrect.
fwiw, bash, dash, zsh, and busybox's sh all allow multiple variables
to be locally scoped with a single declaration, though i recognize
that's not an exhaustive list:
[0 [EMAIL PROTECTED] ~]$ PS1='$? $0$ '
0 bash$ c () { local a b; a=foo; b=bar; echo c: $a $b; } ; c ; echo x: $a $b
c: foo bar
x:
0 bash$ dash
0 dash$ c () { local a b; a=foo; b=bar; echo c: $a $b; } ; c ; echo x: $a $b
c: foo bar
x:
0 dash$ exit
0 bash$ zsh
$? $0$ c () { local a b; a=foo; b=bar; echo c: $a $b; } ; c ; echo x: $a $b
c: foo bar
x:
$? $0$ exit
0 bash$ busybox sh
BusyBox v1.1.3 (Debian 1:1.1.3-5) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
$? $0$ c () { local a b; a=foo; b=bar; echo c: $a $b; } ; c ; echo x: $a $b
c: foo bar
x:
$? $0$ exit
0 bash$
At any rate, the conservative patch is probably the least
objectionable one, even if i'd prefer the liberal one as a shell
script author ;).
Regards,
--dkg
pgphhJziHhmiG.pgp
Description: PGP signature
