After announcing the DUCK challenge last week the following packages were fixed and uploaded into unstable:
What happened about the reproducible
builds effort this week:
Media coverage
Daniel Stender published an English translation of the article which originally
appeared in Linux Magazin in Admin Magazine.
Toolchain fixes
Fixes landed in the Debian archive:
--clamp-mtime option to tar.
Patches have been submitted to add support for SOURCE_DATE_EPOCH to txt2man (Reiner Herrmann), epydoc (Reiner Herrmann), GCC (Dhole), and Doxygen (akira).
Dhole uploaded a new experimental debhelper to the reproducible repository which exports SOURCE_DATE_EPOCH. As part of the experiment, the patch also sets TZ to UTC which should help with most timezone issues. It might still be problematic for some packages which would change their settings based on this.
Mattia Rizzolo sent upstream a patch originally written by Lunar to make the generate-id() function be deterministic in libxslt. While that patch was quickly rejected by upstream, Andrew Ayer came up with a much better one which sadly could have some performance impact. Daniel Veillard replied with another patch that should be deterministic in most cases without needing extra data structures. It's impact is currently being investigated by retesting packages on reproducible.debian.net.
akira added a new option to sbuild for configuring the path in which packages are built. This will be needed for the srebuild script.
Niko Tyni asked Perl upstream about it using the __DATE__ and __TIME__ C processor macros.
Packages fixed
The following 143 packages became reproducible due to changes in their
build dependencies:
alot,
argvalidate,
astroquery,
blender,
bpython,
brian,
calibre,
cfourcc,
chaussette,
checkbox-ng,
cloc,
configshell,
daisy-player,
dipy,
dnsruby,
dput-ng,
dsc-statistics,
eliom,
emacspeak,
freeipmi,
geant321,
gpick,
grapefruit,
heat-cfntools,
imagetooth,
jansson,
jmapviewer,
lava-tool,
libhtml-lint-perl,
libtime-y2038-perl,
lift,
lua-ldoc,
luarocks,
mailman-api,
matroxset,
maven-hpi-plugin,
mknbi,
mpi4py,
mpmath,
msnlib,
munkres,
musicbrainzngs,
nova,
pecomato,
pgrouting,
pngcheck,
powerline,
profitbricks-client,
pyepr,
pylibssh2,
pylogsparser,
pystemmer,
pytest,
python-amqp,
python-apt,
python-carrot,
python-crypto,
python-darts.lib.utils.lru,
python-demgengeo,
python-graph,
python-mock,
python-musicbrainz2,
python-pathtools,
python-pskc,
python-psutil,
python-pypump,
python-repoze.sphinx.autointerface,
python-repoze.tm2,
python-repoze.what-plugins,
python-repoze.what,
python-repoze.who-plugins,
python-xstatic-term.js,
reclass,
resource-agents,
rgain,
rttool,
ruby-aggregate,
ruby-archive-tar-minitar,
ruby-bcat,
ruby-blankslate,
ruby-coffee-script,
ruby-colored,
ruby-dbd-mysql,
ruby-dbd-odbc,
ruby-dbd-pg,
ruby-dbd-sqlite3,
ruby-dbi,
ruby-dirty-memoize,
ruby-encryptor,
ruby-erubis,
ruby-fast-xs,
ruby-fusefs,
ruby-gd,
ruby-git,
ruby-globalhotkeys,
ruby-god,
ruby-hike,
ruby-hmac,
ruby-integration,
ruby-ipaddress,
ruby-jnunemaker-matchy,
ruby-memoize,
ruby-merb-core,
ruby-merb-haml,
ruby-merb-helpers,
ruby-metaid,
ruby-mina,
ruby-net-irc,
ruby-net-netrc,
ruby-odbc,
ruby-packet,
ruby-parseconfig,
ruby-platform,
ruby-plist,
ruby-popen4,
ruby-rchardet,
ruby-romkan,
ruby-rubyforge,
ruby-rubytorrent,
ruby-samuel,
ruby-shoulda-matchers,
ruby-sourcify,
ruby-test-spec,
ruby-validatable,
ruby-wirble,
ruby-xml-simple,
ruby-zoom,
ryu,
simplejson,
spamassassin-heatu,
speaklater,
stompserver,
syncevolution,
syncmaildir,
thin,
ticgit,
tox,
transmissionrpc,
vdr-plugin-xine,
waitress,
whereami,
xlsx2csv,
zathura.
The following packages became reproducible after getting fixed:
debian/changelog entry as build datedebian/changelog entry.#defines..
-i/--issues: schedule all packages affected by the given issue.-r/--status: schedule all packages with the given status.-b/--before: schedule all packages built before the given date-t/--after: schedule all packages built after the given date.--noisy: notify the IRC channel also when the build starts, with a URL to watch it in real time. What happened about the reproducible
builds effort for this week:
Toolchain fixes
Dpkg::Dist::Files files list on output to make the output stable with parallel builds.xpi-pack to skip saving extra zip attributes when making jar.sort in the buildinfo generator prevented a stable order and was quickly
fixed once identified.
Mattia Rizzolo also rebased our custom
debhelper on the latest release.
Packages fixed
The following 30 packages became reproducible due to changes in their
build dependencies:
animal-sniffer,
asciidoctor,
autodock-vina,
camping,
cookie-monster,
downthemall,
flashblock,
gamera,
httpcomponents-core,
https-finder,
icedove-l10n,
istack-commons,
jdeb,
libmodule-build-perl,
libur-perl,
livehttpheaders,
maven-dependency-plugin,
maven-ejb-plugin,
mozilla-noscript,
nosquint,
requestpolicy,
ruby-benchmark-ips,
ruby-benchmark-suite,
ruby-expression-parser,
ruby-github-markup,
ruby-http-connection,
ruby-settingslogic,
ruby-uuidtools,
webkit2gtk,
wot.
The following packages became reproducible after getting fixed:
debian/changelog as build date.debian/changelog as documentation build date.debian/changelog as reference.debian/changelog as build date.debian/changelog as documentation build date.Storable::nstore to produce sorted output.DATE, WHOAMI, andHOSTNAME_CMD to stable values.debian/changelog as documentation build date.debian/changelog as documentation build date.debian/changelog as documentation build date.deadwood binary.--distrobuild build switch.locales-all is installed instead of locales.debbindiff.pom.properties files.
debbindiff development
At the request of Emmanuel Bourg, Reiner Herrmann added a comparator for Java
.class files.
Documentation update
Christoph Berg created a new page for the timestamps in manpages created by
Doxygen.
Package reviews
93 obsolete
reviews have
been removed, 76 added and 43 updated this week.
New identified issues: timestamps in manpages generated by Doxygen, modification time differences in files extracted by unzip, tstamp task used in Ant build.xml, timestamps in documentation generated by ASDocGen. The description for build id related issues has been clarified.
Meetings
Holger Levsen announced a first
meeting on Wednesday,
June 3rd, 2015, 19:00 UTC. The agenda is amendable on the wiki.
Misc.
Lunar worked on a proof-of-concept script to import the build environment found
in .buildinfo
files to
UDD. Lucas Nussbaum has positively reviewed the
proposed schema.
Holger Levsen cleaned up various experimental toolchain repositories, marking
merged brances as such.
What happened about the reproducible
builds effort for this week:
Toolchain fixes
Uploads that should help other packages:
dlltool's temp prefix so it generates reproducible files.dlltool to initialize its output's .idata$6 section, avoiding random data ending up there.package-tree.html produced by javadoc.--no-insert-timestamps be the default in binutils-mingw-w64? (Stephen Kitt)--deterministic option to Tar? (Lunar)-flto -ffat-lto-objects (Lunar)debian/changelog entry, prevent gzip from storing a timestamp.debian/changelog.__DATE__ and __TIME__ macros.#debian-reproducible IRC channel if you want to be notified for your packages!
strip-nondeterminism development
Andrew Ayer fixed the gzip handler so that it skip adding a predetermined timestamp when there was none.
Documentation update
Lunar added documentation about mtimes of file extracted using unzip being timezone dependent. He also wrote a short example on how to test reproducibility.
Stephen Kitt updated the documentation about timestamps in PE binaries.
Documentation and scripts to perform weekly reports were published by Lunar.
Package reviews
50 obsolete
reviews have
been removed, 51 added and 29 updated this week. Thanks Chris West and Mathieu
Bridon amongst others.
New identified issues:
What happened about the reproducible
builds effort for this week:
Presentations
On June 7th, Reiner Herrmann
presented the project at the
Gulaschprogrammiernacht 15 in Karlsruhe, Germany.
Video and audio
recordings
in German are available, and so are the slides in
English.
Toolchain fixes
dh_installtex.SOURCE_DATE_EPOCH with a value suitable for gmtime(3).
debian/rules in packages using it to produce HTML documentation.--mtime when creating source tarball.HTML_TIMESTAMP to NO in Doxygen configuration file.HTML_TIMESTAMP to NO in Doxygen configuration file.Makefile.PL.debbindiff to be better understood. (h01ger)
debbindiff development
Reiner Herrmann added support for decompling Java .class file and .ipk package files (used by OpenWrt). This is now available in version 22 released on 2015-06-14.
Documentation update
Stephen Kitt
documented
the new --insert-timestamp available since
binutils-mingw-w64 version 6.2
available to insert a ready-made date in PE binaries built with
mingw-w64.
Package reviews
195 obsolete
reviews have
been removed, 65 added and 126 updated this week.
New identified issues:
Provides: locales but is actually missing some of the files provided by locales.
Coreboot upstream has been quick to react after the
announcement
of the tests set up the week
before. Patrick Georgi has fixed all issues in a couple of days and all
Coreboot images are now reproducible (without a payload).
SeaBIOS is one of the most frequently used payload
on PC hardware and can now be made
reproducible
too.
Paul Kocialkowski wrote to the mailing
list
asking for help on getting U-Boot tested for
reproducibility.
Lunar had a chat with maintainers of Open Build
Service to better
understand the difference between their system and what we are doing for
Debian.
What happened about the reproducible
builds effort for this week:
Presentations
On May 26th,Holger Levsen presented reproducible builds in Debian at CCC Berlin for the Datengarten 52. The presentation was in German and the slides in English. Audio and video recordings are available.
Toolchain fixes
pyuic output imports in stable order. Original patch by Reiner Herrmann.zip or unzip.control.tar. The patch has also been submitted based on the main branch.
Daniel Kahn Gillmor proposed a patch to add support for externally-supplying build date to help2man. This sparkled a discussion about agreeing on a common name for an environment variable to hold the date that should be used. It seems opinions are converging on using SOURCE_DATE_UTC which would hold a ISO-8601 formatted date in UTC) (e.g. 2015-06-05T01:08:20Z). Kudos to Daniel, Brendan O'Dea, Ximin Luo for pushing this forward.
Lunar proposed a patch to Tar upstream adding a --clamp-mtime option as a generic solution for timestamp variations in tarballs which might also be useful for dpkg. The option changes the behavior of --mtime to only use the time specified if the file mtime is newer than the given time. So far, upstream is not convinced that it would make a worthwhile addition to Tar, though.
Daniel Kahn Gillmor reached out to the libburnia project to ask for help on how to make ISO created with xorriso reproducible. We should reward Thomas Schmitt with a model upstream trophy as he went through a thorough analysis of possible sources of variations and ways to improve the situation. Most of what is missing with the current version in Debian is available in the latest upstream version, but libisoburn in Debian needs help. Daniel backported the missing option for version 1.3.2-1.1.
akira submitted a new issue to Doxygen upstream regarding the timestamps added to the generated manpages.
Packages fixed
The following 49 packages became reproducible due to changes in their
build dependencies:
activemq-protobuf,
bnfc,
bridge-method-injector,
commons-exec,
console-data,
djinn,
github-backup,
haskell-authenticate-oauth,
haskell-authenticate,
haskell-blaze-builder,
haskell-blaze-textual,
haskell-bloomfilter,
haskell-brainfuck,
haskell-hspec-discover,
haskell-pretty-show,
haskell-unlambda,
haskell-x509-util,
haskelldb-hdbc-odbc,
haskelldb-hdbc-postgresql,
haskelldb-hdbc-sqlite3,
hasktags,
hedgewars,
hscolour,
https-everywhere,
java-comment-preprocessor,
jffi,
jgit,
jnr-ffi,
jnr-netdb,
jsoup,
lhs2tex,
libcolor-calc-perl,
libfile-changenotify-perl,
libpdl-io-hdf5-perl,
libsvn-notify-mirror-perl,
localizer,
maven-enforcer,
pyotherside,
python-xlrd,
python-xstatic-angular-bootstrap,
rt-extension-calendar,
ruby-builder,
ruby-em-hiredis,
ruby-redcloth,
shellcheck,
sisu-plexus,
tomcat-maven-plugin,
v4l2loopback,
vim-latexsuite.
The following packages became reproducible after getting fixed:
modified-by option.__DATE__ and __TIME__ macros from source.debian/changelog entry in manpage.debian/changelog entry.HTML_TIMESTAMP to NO in Doxygen configuration.HTML_TIMESTAMP to NO in Doxygen configuration.HTML_TIMESTAMP set to NO.$datetime from the file api_footer.html.$datetime from the file footer.html.$PATH. The second build will be done with a /i/capture/the/path added. (Holger Levsen)
Holger Levsen with the help of Alexander Couzens wrote extra job to test the reproducibility of coreboot. Thanks James McCoy for helping with certificate issues.
Mattia Rizollo made some more internal improvements.
strip-nondeterminism development
Andrew Ayer released strip-nondeterminism/0.008-1. This new version fixes the gzip handler so that it now skip adding a predetermined timestamp when there was none.
Holger Levsen sponsored the upload.
Documentation update
The pages about timestamps in manpages generated by Doxygen, GHC .hi files, and Jar files have been updated to reflect their status in upstream.
Markus Koschany documented an easy way to prevent Doxygen to write timestamps in HTML output.
Package reviews
83 obsolete
reviews have
been removed, 71 added and 48 updated this week.
Meetings
A meeting was held on 2015-06-03. Minutes and full logs are available.
It was agreed to hold such a meeting every two weeks for the time being. The time of the next meeting should be announced soon.
I encourage anyone interested in debian development to get involved with the Reproducible Builds project. My own project is to try to diagnose (and hopefully provide patches for) two unreproducible packages a week. Maybe you can do one package a week? Reproducible Builds is another example of the kind of audacious project that I celebrated in my last blog post. It's a fun way to learn a little bit about different parts of the archive, and to help on an incrementally-improving process. My workflow below is meant to encourage folks to join in. The documentation on the wiki is certainly more authoritative (and will be more up-to-date in the future). My usual workflow is this: debcheckout clocIf that failed for some reason, I would use:
apt-get source cloc
Source: packagename Version: packageversion Tags: patch Severity: wishlist User: reproducible-builds@lists.alioth.debian.org Usertags: closest-usertag X-Debbugs-CC: reproducible-builds@lists.alioth.debian.orgWhen choosing the
closest usertag, i look at the "Usertagged bugs" block on the R-B continuous integration dashboard or the wiki documentation to see what makes sense.
DebConf15 will be held in Heidelberg, Germany from the 15th to the 22nd of
August, 2015. The clock is ticking and our annual conference is approaching.
There are less than three months to go, and the Call for Proposals period
closes in only a few weeks.
This year, we are encouraging people to submit half-length 20-minute events,
to allow attendees to have a broader view of the many things that go on in the
project in the limited amount of time that we have.
To make sure that your proposal is part of the official DebConf schedule you
should submit it before June 15th.
If you have already sent your proposal, please log in to summit and make sure
to improve your description and title. This will help us fit the talks into
tracks, and devise a cohesive schedule.
For more details on how to submit a proposal see: http://debconf15.debconf.org/proposals.xhtml.
Approved Talks
We have processed the proposals submitted up to now, and we are proud to
announce the first batch of approved talks. Some of them:
What happened about the reproducible
builds effort for this week:
Toolchain fixes
contrib:
Thanks to the reproducible-build team for running a buildd from hell. gregor herrmannMattia Rizzolo modified the script added last week to reschedule a package from Alioth, a reason can now be optionally specified. Holger Levsen splitted the package sets page so each set now has its own page. He also added new sets for Java packages, Haskell packages, Ruby packages, debian-installer packages, Go packages, and OCaml packages. Reiner Herrmann added locales-all to the set of packages installed in the build environment as its needed to properly identify variations due to the current locale. Holger Levsen improved the scheduling so new uploads get tested sooner. He also changed the
.json output that is used by
tracker.debian.org to lists FTBFS issues again
but only for issues unrelated to the toolchain or our test setup. Amongst many
other small fixes and additions, the graph colors should now be
more friendly to red-colorblind people.
The fix for pbuilder given in
#677666 by Tim Landscheidt is now used. This
fixed several FTBFS for OCaml packages.
Work on rebuilding with different CPU has continued, a kvm-on-kvm build host
has been set been set up for this purpose.
debbindiff development
Version 19 of
debbindiff included a fix for a
regression when handling info files.
Version 20 fixes a bug when diffing
files with many differences toward a last line with no newlines. It also now
uses the proper encoding when writing the text output to a
pipe, and detects info files better.
Documentation update
Thanks to Santiago Vila, the unneeded -depth option used with find when
fixing mtimes has been removed from the examples.
Package reviews
113 obsolete
reviews have
been removed this week while 77 has been added.
What happened about the reproducible
builds effort for this week:
Media coverage
Debian's effort on reproducible builds has been covered in the June 2015 issue of
Linux Magazin in
Germany.
Toolchain fixes
debian/changelog entry when generating documentation.debian/changelog entry to Sphinx.sed instead of grep+mv to keep correct file permissions.PERL_HASH_SEED=0 during configure to make the generated .c and .h files stable.--disable-build-date to ./configure.debian/changelog entry as build date.debian/chanelog entry as build date.reproducible.debian.net how it goes for pathological cases.
It's now possible to specify both --html and --text output. When neither of
them is specified, the default will be to print a text report on the standard
output (thanks to Paul Wise for the suggestion).
Documentation update
Nicolas Boulenguez investigated Ada
libraries.
Package reviews
451 obsolete
reviews have
been removed and 156 added this week.
New identified issues: running kernel version getting captured, random filenames in GHC debug symbols, and timestamps in headers generated by qdbusxml2cpp.
Misc.
Holger Levsen went to re:publica and talked about
reproducible builds to developers and users there.
Holger also had a chance to meet FreeBSD developers and discuss the status of
FreeBSD. Investigations have
started on how it could be made part of our current test
system.
Laurent Guerby gave Lunar access to systems in the GCC Compile
Farm. Hopefully access to these powerful
machines will help to fix packages for GCC, Iceweasel, and similar packages
requiring long build times.
When paultag recently announced a project to try to move debian infrastructure to python3, my first thought was how large that undertaking would likely be. It seems like a classic engineering task, full of work and nit-picky details to get right, useful/necessary in the long-term, painful in the short-term, and if you manage to pull it off successfully, the best you can usually hope for is that no one will notice that it was done at all. I always find that kind of task a little off-putting and difficult to tackle, but I was happy to see someone driving the project, since it does need to get done. Debian is potentially also in a position to help the upstream python community, because we have a pretty good view of what things are being used, at least within our own ecosystem. I'm happy to say that i also missed one of the other great benefits of paultag's audacious proposal, which is how it has engaged people who already knew about debian but who aren't yet involved. Evidence of this engagement is already visible on the py3porters-devel mailing list. But if that wasn't enough, I ran into a friend recently who told me, "Hey, I found a way to contribute to debian finally!" and pointed me to the py3-porters project. People want to contribute to the project, and are looking for ways in. So cheers to the people who propose audacious projects and make them inviting to everyone, newcomers included. And cheers to the people who step up to potentially daunting work, stake out a task, roll up their sleeves, and pitch in. Even if the py3porters project doesn't move all of debian's python infrastructure to pyt3 as fast as paultag wants it to, i think it's already a win for the project as a whole. I am looking forward to seeing what comes out of it (and it's reminding me i need to port some of my own python work, too!) The next time you stumble over something big that needs doing in debian, even something that might seem impossible, please make it inviting, and dive in. The rest of the project will grow and improve from the attempt.Tags: py3-porters
I just took a few minutes to write up my preferred Debian packaging practices. The basic gist is that i like to use git-buildpackage (gbp) with the upstream source included in the repo, both as tarballs (with pristine-tar branches) and including upstream's native VCS history (Joey's arguments about syncing with upstream git are worth reading if you're not already convinced this is a good idea). I also started using gbp-pq recently -- the patch-queue feature is really useful for at least three things: I'm using grub version 2.02~beta2-2. I want to make a USB stick that's capable of booting Intel architecture EFI machines, both 64-bit (x86_64) and 32-bit (ia32). I'm starting from a USB stick which is attached to a running debian system as /dev/sdX. I have nothing that i care about on that USB stick, and all data on it will be destroyed by this process. I'm also going to try to make it bootable for traditional Intel BIOS machines, since that seems handy.I'm documenting what I did here, in case it's useful to other people. Set up the USB stick's partition table: parted /dev/sdX -- mktable gpt parted /dev/sdX -- mkpart biosgrub fat32 1MiB 4MiB parted /dev/sdX -- mkpart efi fat32 4MiB -1 parted /dev/sdX -- set 1 bios_grub on parted /dev/sdX -- set 2 esp onAfter this, my 1GiB USB stick looks like:
0 root@foo:~# parted /dev/sdX -- print Model: USB FLASH DRIVE (scsi) Disk /dev/sdX: 1032MB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 1 1049kB 4194kB 3146kB fat32 biosgrub bios_grub 2 4194kB 1031MB 1027MB efi boot, esp 0 root@foo:~#make a filesystem and mount it temporarily at /mnt:
mkfs -t vfat -n GRUB /dev/sdX2 mount /dev/sdX2 /mntensure we have the binaries needed, and add three grub targets for the different platforms:
apt install grub-efi-ia32-bin grub-efi-amd64-bin grub-pc-bin grub2-common
grub-install --removable --no-nvram --no-uefi-secure-boot \
--efi-directory=/mnt --boot-directory=/mnt \
--target=i386-efi
grub-install --removable --no-nvram --no-uefi-secure-boot \
--efi-directory=/mnt --boot-directory=/mnt \
--target=x86_64-efi
grub-install --removable --boot-directory=/mnt \
--target=i386-pc /dev/sdX
At this point, you should add anything else you want to /mnt here! For example: umount /mnt syncTags: bios, efi, grub, tip
The abbreviated title above means "Appreciation for Localization" :) I wanted to say a word of thanks for the awesome work done by debian localization teams. I speak English, and my other language skills are weak. I'm lucky: most software I use is written by default in a language that I can already understand. The debian localization teams do great work in making sure that packages in debian gets translated into many other languages, so that many more people around the world can take advantage of free software. I was reminded of this work recently (again) with the great patches submitted to GnuPG and related packages. The changes were made by many different people, and coordinated with the debian GnuPG packaging team by David Pr vot. This work doesn't just help debian and its users. These localizations make their way back upstream to the original projects, which in turn are available to many other people. If you use debian, and you speak a language other than english, and you want to give back to the community, please consider joining one of the localization teams. They are a great way to help out our project's top priorities: our users and free software. Thank you to all the localizers! (this post was inspired by gregoa's debian advent calendar. i won't be posting public words of thanks as frequently or as diligently as he does, any more than i'll be fixing the number of RC bugs that he fixes. This are just two of the ways that gregoa consistently leads the community by example. He's an inspiration, even if living up to his example is a daunting challenge.)
Today, i uploaded GnuPG 2.1.0 into debian's experimental suite. It's built for amd64 and i386 and powerpc already. You can monitor its progress on the buildds to see when it's available for your architecture. ChangesGnuPG 2.1 offers many new and interesting features, but one of the most important changes is the introduction of elliptic curve crypto (ECC). While GnuPG 2.1 discourages the creation of ECC keys by default, it's important that we have the ability to verify ECC signatures and to encrypt to ECC keys if other people are using this tech. It seems likely, for example, that Google's End-To-End Chrome OpenPGP extension will use ECC. GnuPG users who don't have this capability available won't be able to communicate with End-To-End users. There are many other architectural changes, including a move to more daemonized interactions with the outside world, including using dirmngr to talk to the keyservers, and relying more heavily on gpg-agent for secret key access. The gpg-agent change is a welcome one -- the agent now holds the secret key material entirely and never releases it -- as of 2.1 gpg2 never has any asymmetric secret key material in its process space at all. One other nice change for those of us with large keyrings is the new keybox format for public key material. This provides much faster indexed access to the public keyring. I've been using GnuPG 2.1.0 betas regularly for the last month, and i think that for the most part, they're ready for regular use. Timing for debian The timing between the debian freeze and the GnuPG upstream is unfortunate, but i don't think i'm prepared to push for this as a jessie transition yet, without more backup. I'm talking to other members of the GnuPG packaging team to see if they think this is worth even bringing to the attention of the release team, but i'm not pursuing it at the moment. If you really want to see this in debian jessie, please install the experimental package and let me know how it works for you. Long term migration concerns GnuPG upstream is now maintaining three branches concurrently: modern (2.1.x), stable (2.0.x), and classic (1.4.x). I think this is stretches the GnuPG upstream development team too thin, and we should do what we can to help them transition to supporting fewer releases concurrently. In the long-term, I'd ultimately like to see gnupg 2.1.x to replace all use of gpg 1.4.x and gpg 2.0.x in debian, but unlikely to to happen right now. In particular, the following two bugs make it impossible to use my current, common monkeysphere workflow: cp -aT .gnupg .gnupg.bak sudo apt install -t experimental gnupg2 gnupg-agent dirmngr gpgsm gpgv2 scdaemonIf you find issues, please file them via the debian BTS as usual. I (or other members of the pkg-gnupg team) will help you triage them to upstream as needed. Tags: ecc, experimental, gnupg
I love to see there is a lot of crypto discussions going on at DebConf. Maybe I'm skewed by my role as keyring-maint, but I have been involved in more than one discussion every day on what do/should signatures mean, on best key handling practices, on some ideas to make key maintenance better, on how the OpenPGPv4 format lays out a key and its components on disk, all that. I enjoy some of those discussions pose questions that leave me thinking, as I am quite far from having all answers.
Discussions should be had face to face, but some start online and deserve to be answered online (and also pose opportunity to become documentation). Simon Josefsson blogs about The case for short OpenPGP key validity periods. This will be an important issue to tackle, as we will soon require keys in the Debian keyring to have a set expiration date (surprise surprise!) and I agree with Simon, setting an expiration date far in the future means very little.
There is a caveat with using, as he suggests, very short expiry periods: We have a human factor sitting in the middle. Keyring updates in Debian are done approximately once a month, and I do not see the period shortening. That means, only once a month we (currently Jonathan McDowell and myself, and we expect to add Daniel Kahn Gillmor soon) take the full changeset and compile a new keyring that replaces the active one in Debian.
This means that if you have, as Simon suggests, a 100-day validity key, you have to remember to update it at least every 70 days, or you might be locked out during the days it takes us to process it.
I set my expiration period to two years, although I might shorten it to only one. I expect to add checks+notifications before we enable this requirement project-wide (so that Debian servers will mail you when your key is close to expiry); I think that mail can be sent at approximately [expiry date - 90 days] to give you time both to you and to us to act. Probably the optimal expiration periods under such conditions would be between 180 and 365 days.
But, yes, this is by far not yet a ruling, but a point in the discussion. We still have some days of DebConf, and I'll enjoy revising this point. And Simon, even if we correct some bits for these details, I'd like to have your permission to use this fine blog post as part of our documentation!
(And on completely unrelated news: Congratulations to our dear and very much missed friend Bubulle for completely losing his sanity and running for 28 hours and a half straight! He briefly describes this adventure when it was about to start, and we all want him to tell us how it was. Mr. Running French Guy, you are amazing!)
I'm replacing my OTR key for XMPP because of heartbleed (see below). If the plain ASCII text below is mangled beyond verification, you can retrieve a copy of it from my web site that should be able to be verified. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OTR Key Replacement for XMPP dkg@jabber.org =========================================== Date: 2014-04-14 My main XMPP account is dkg@jabber.org. I prefer OTR [0] conversations when using XMPP for private discussions. I was using irssi to connect to XMPP servers, and irssi relies on OpenSSL for the TLS connections. I was using it with versions of OpenSSL that were vulnerable to the "Heartbleed" attack [1]. It's possible that my OTR long-term secret key was leaked via this attack. As a result, I'm changing my OTR key for this account. The new, correct OTR fingerprint for the XMPP account at dkg@jabber.org is: F8953C5D 48ABABA2 F48EE99C D6550A78 A91EF63D Thanks for taking the time to verify your peers' fingerprints. Secure communication is important not only to protect yourself, but also to protect your friends, their friends and so on. Happy Hacking, --dkg (Daniel Kahn Gillmor) Notes: [0] OTR: https://otr.cypherpunks.ca/ [1] Heartbleed: http://heartbleed.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJTTBF+XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcYwkQAKLzEnTV1lrK6YrhdvRnuYnh Bh9Ad2ZY44RQmN+STMEnCJ4OWbn5qx/NrziNVUZN6JddrEvYUOxME6K0mGHdY2KR yjLYudsBuSMZQ+5crZkE8rjBL8vDj8Dbn3mHyT8bAbB9cmASESeQMu96vni15ePd 2sB7iBofee9YAoiewI+xRvjo2aRX8nbFSykoIusgnYG2qwo2qPaBVOjmoBPB5YRI PkN0/hAh11Ky0qQ/GUROytp/BMJXZx2rea2xHs0mplZLqJrX400u1Bawllgz3gfV qQKKNc3st6iHf3F6p6Z0db9NRq+AJ24fTJNcQ+t07vMZHCWM+hTelofvDyBhqG/r l8e4gdSh/zWTR/7TR3ZYLCiZzU0uYNd0rE3CcxDbnGTUS1ZxooykWBNIPJMl1DUE zzcrQleLS5tna1b9la3rJWtFIATyO4dvUXXa9wU3c3+Wr60cSXbsK5OCct2KmiWY fJme0bpM5m1j7B8QwLzKqy/+YgOOJ05QDVbBZwJn1B7rvUYmb968yLQUqO5Q87L4 GvPB1yY+2bLLF2oFMJJzFmhKuAflslRXyKcAhTmtKZY+hUpxoWuVa1qLU3bQCUSE MlC4Hv6vaq14BEYLeopoSb7THsIcUdRjho+WEKPkryj6aVZM5WnIGIS/4QtYvWpk 3UsXFdVZGfE9rfCOLf0F =BGa1 -----END PGP SIGNATURE-----
We changed the default PGP signatures generated by enigmail in debian from Inline PGP to PGP/MIME last year, and the experiment has gone well enough that we're now using it in jessie and wheezy (where it arrived as part of a security update to make the extension work with the security-updated icedove package). After having several people poke me in different contexts about why inline cleartext PGP signatures are a bad idea, i got sufficiently tired of repeating myself, and finally documented some of the problems explicitly. The report includes a demonstration of a content-tampering attack that changes the meaning of a signed inline-PGP message without breaking the signature, which i first worked out on the notmuch mailing list, but hadn't gotten around to demonstrating until recently. The attack is demonstrated against clearsigned messages, but also works against inline encrypted messages (but is harder to demonstrate since a demonstration would require sharing secret key material for the decryption step). Please don't generate Inline-PGP messages. And if you must parse and accept them, please consider carefully the risks you expose your users to and think about ways to mitigate the problems.Tags: charset, inline-pgp, openpgp, security
I've said recently that pervasive surveillance is wrong. I don't think anyone from the NSA should have a leadership position in the development or deployment of Internet communications, because their interests are at odds with the interest of the rest of the Internet. But someone at the NSA is in exactly such a position. They ought to step down. Here's the background: The Internet Research Task Force (IRTF) is a body tasked with research into underlying concepts, themes, and technologies related to the Internet as a whole. They act as a research organization that cooperates and complements the engineering and standards-setting activities of the Internet Engineering Task Force (IETF). The IRTF is divided into issue-specific research groups, each of which has a Chair or Co-Chairs who have "wide discretion in the conduct of Research Group business", and are tasked with organizing the research and discussion, ensuring that the group makes progress on the relevant issues, and communicating the general sense of the results back to the rest of the IRTF and the IETF. One of the IRTF's research groups specializes in cryptography: the Crypto Forum Research Group (CFRG). There are two current chairs of the CFRG: David McGrew <mcgrew@cisco.com> and Kevin M. Igoe <kmigoe@nsa.gov>. As you can see from his e-mail address, Kevin M. Igoe is affiliated with the National Security Agency (NSA). The NSA itself actively tries to weaken cryptography on the Internet so that they can improve their surveillance, and one of the ways they try to do so is to "influence policies, standards, and specifications". On the CFRG list yesterday, Trevor Perrin requested the removal of Kevin M. Igoe from his position as Co-chair of the CFRG. Trevor's specific arguments rest heavily on the technical merits of a proposed cryptographic mechanism called Dragonfly key exchange, but I think the focus on Dragonfly itself is the least of the concerns for the IRTF. I've seconded Trevor's proposal, and asked Kevin directly to step down and to provide us with information about any attempts by the NSA to interfere with or subvert recommendations coming from these standards bodies. Below is my letter in full: I'm aware that an abdication by Kevin (or his removal by the IETF chair) would probably not end the NSA's attempts to subvert standards bodies or weaken encryption. They could continue to do so by subterfuge, for example, or by private influence on other public members. We may not be able to stop them from doing this in secret, and the knowledge that they may do so seems likely to cast a pall of suspicion over any IETF and IRTF proceedings in the future. This social damage is serious and troubling, and it marks yet another cost to the NSA's reckless institutional disregard for civil liberties and free communication. But even if we cannot rule out private NSA influence over standards bodies and discussion, we can certainly explicitly reject any public influence over these critical communications standards by members of an institution so at odds with the core principles of a free society. Kevin M. Igoe, please step down from the CFRG Co-chair position. And to anyone (including Kevin) who knows about specific attempts by the NSA to undermine the communications standards we all rely on: please blow the whistle on this kind of activity. Alert a friend, a colleague, or a journalist. Pervasive surveillance is an attack on all of us, and those who resist it are heroes.From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: cfrg@ietf.org, Kevin M. Igoe <kmigoe@nsa.gov> Date: Sat, 21 Dec 2013 16:29:13 -0500 Subject: Re: [Cfrg] Requesting removal of CFRG co-chair On 12/20/2013 11:01 AM, Trevor Perrin wrote: > I'd like to request the removal of Kevin Igoe from CFRG co-chair. Regardless of the conclusions that anyone comes to about Dragonfly itself, I agree with Trevor that Kevin M. Igoe, as an employee of the NSA, should not remain in the role of CFRG co-chair. While the NSA clearly has a wealth of cryptographic knowledge and experience that would be useful for the CFRG, the NSA is apparently engaged in a series of attempts to weaken cryptographic standards and tools in ways that would facilitate pervasive surveillance of communication on the Internet. The IETF's public position in favor of privacy and security rightly identifies pervasive surveillance on the Internet as a serious problem: https://www.ietf.org/media/2013-11-07-internet-privacy-and-security.html The documents Trevor points to (and others from similar stories) indicate that the NSA is an organization at odds with the goals of the IETF. While I want the IETF to continue welcoming technical insight and discussion from everyone, I do not think it is appropriate for anyone from the NSA to be in a position of coordination or leadership. ---- Kevin, the responsible action for anyone in your position is to acknowledge the conflict of interest, and step down promptly from the position of Co-Chair of the CFRG. If you happen to also subscribe to the broad consensus described in the IETF's recent announcement -- that is, if you care about privacy and security on the Internet -- then you should also reveal any NSA activity you know about that attempts to subvert or weaken the cryptographic underpinnings of IETF protocols. Regards, --dkg
Next.