Re: Replacing isc-dhcp-client with dhcpcd-base (Was: ifupdown maintenance)

[Henrique de Moraes Holschuh]

On Sat, Sep 14, 2024, at 09:30, Daniel Gröber wrote:
>  3) dhcpcd-base enables IPv6 privacy addressess by default.

Please never do this *by silent default* when DHCPv6 is being used for stateful 
address assignment, privacy addresses are a big issue on non-home networks and 
even on home networks depending on firewall rules...

Although I suppose a relevant note on NEWS.Debian *and* the Release Notes might 
be enough if.we consider it is desirable for most installs.

> 3) Since ifupdown is mainly used in the server/embedded sorts of
> enviornments I'm not sure privacy addressing is the right default.
> (cf. /etc/dhcpcd.conf having `slaac private` thus enabling RFC 7217
> addressing). We can assume NM will be in use for most Desktop users so I
> believe it's safe in principle to retain the current MAC based SLAAC
> address behaviour we used to get from the kernel RA implementation.
> Thoughts?

Agreed, the less surprises here, the better.

-- 
  Henrique de Moraes Holschuh 

Re: Debian openssh option review: considering splitting out GSS-API key exchange

[Henrique de Moraes Holschuh]

On Tue, Apr 2, 2024, at 07:04, Marco d'Itri wrote:
> On Apr 02, Colin Watson  wrote:
>
>> At the time, denyhosts was popular, but it was removed from Debian
>> several years ago.  I remember that, when I dealt with that on my own
>> systems, fail2ban seemed like the obvious replacement, and my impression
>> is that it's pretty widely used nowadays; it's very pluggable but it
>> normally works by adding firewall rules.  Are there any similar popular
>> systems left that rely on editing /etc/hosts.deny?
> Yes, people. I object to removing TCP wrappers support since the patch 
> is tiny and it supports use cases like DNS-based ACLs which cannot be 
> supported by L3 firewalls.

If libwrap is bringing in complex libs, maybe we could reduce the attack 
surface on libwrap itself?  It would be nice to have a variant that only links 
to the libc and that's it...

And that benefits everything that links to TCP wrappers...

I also like to have the (old-school) standard extra layer of protection that 
libwrap can provide. I'd like to find a way to keep it useful for sshd.

-- 
  Henrique de Moraes Holschuh 

Re: xz backdoor

[Henrique de Moraes Holschuh]

On Sat, Mar 30, 2024, at 05:49, Jonathan Carter wrote:

> Another big question for me is whether I should really still 
> package/upload/etc from an unstable machine. It seems that it may be 

I have been using stable or old stable + pbuilder for this.  Test runs of the 
results might need a VM though, when stable + container is not enough.

-- 
  Henrique de Moraes Holschuh 

Re: Populating non-free firmware?

[Henrique de Moraes Holschuh]

On Sun, Dec 25, 2022, at 15:21, Jonathan Carter wrote:
> So if we're going with maintainers-are-going-to-do-the-uploads, then 
> taking a cursory glance at what's left that seems important is:
>
>   - firmware-sof-signed (maintainer: Mark Pearson)
>   - intel-microcode (maintainer: Henrique de Moraes Holschuh)
>   - amd64-microcode (maintainer: Henrique de Moraes Holschuh)

Please email me directly when it is time to do such upload changing the archive 
section.

I assume we (maintainers) don't need to do the usual dance of opening a bug to 
change the Dak override file for the package section ?  There is no point to 
any uploads before that file is updated AFAIK.

-- 
  Henrique de Moraes Holschuh 

Re: Bug#987980: ITP: infamous-plugins -- Infamous Plugins is a collection of open-source LV2 plugins

[Henrique de Moraes Holschuh]

Hello Fernando,

On Mon, May 3, 2021, at 03:32, Fernando Toledo wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Fernando Toledo 
> 
> * Package name: infamous-plugins

Please consider a prefix for the source package and binary package name, maybe 
lv2- or lv2-audio- or something else more suitable...

After all, lv2 is not the only thing with infamous plugins out there ;-)

-- 
  Henrique de Moraes Holschuh 

Re: Bug#982945: ITP: asyncfuture -- Enhanced Qfuture (Qt) interface

[Henrique de Moraes Holschuh]

Wookey,

>   Description : Enhanced Qfuture (Qt) interface
> 
>  AsyncFuture is designed to enhance the QFuture function, removing..

Maybe this should be prefixed with qt- since it is qt-specific and otherwise 
somewhat a generic naming?


-- 
  Henrique de Moraes Holschuh 

Re: Making Debian available

[Henrique de Moraes Holschuh]

On Mon, Jan 25, 2021, at 16:34, Andrei POPESCU wrote:
> On Lu, 25 ian 21, 19:35:25, Thomas Lange wrote:
> > Another very odd thing I found.
> > 
> > On https://www.debian.org/CD/faq/
> > there's no hint about images including non-free firmware. No hint
> > about firmware at all. And then this FAQ
> > 
> > 
> > Where is the CD image with non-free?
> >   .
> > Sometimes, someone is kind enough to create unofficial non-free CDs. If you 
> > cannot find any links on this website, you can try asking on the debian-cd 
> > mailing list.
> > 
> > 
> > So we do not tell our users that we (the CD team I guess) already
> > create these very usefull images including non-free firmware. And then
> > we tell the users to search the link themselves. Not very friendly.
> 
> As far as I recall that entry refers to CDs with the entire non-free 
> component of the archive, not just firmware packages (which were seldom 
> or even inexistent at the time the FAQ was written).

That's correct.  It is not about non-free firmware, but rather the non-free 
distribution as a whole.

That FAQ entry neither explains things well enough, nor is it very helpful.  It 
could use an update...

Heck, I am not even sure the installer could use anything in that non-free CD 
set to actually load non-free firmware at *install time* (as opposed to 
installing it to be available on the final system after a reboot) without a lot 
of manual intervention...

-- 
  Henrique de Moraes Holschuh 

Re: Release status of i386 for Bullseye and long term support for 3 years?

[Henrique de Moraes Holschuh]

On Sat, Dec 12, 2020, at 13:09, Adrian Bunk wrote:
> 3. Computers that do support MMX and SSE2, but do not support 64bit.

The "Centrino" Pentium-M that you can find on a reasonably lot of still-working 
ThinkPads (the T4x series and similar X/R series of the time), for example.  
Note that this is "family 6" Pentium-M processors, not "family 15" Pentium4-M.

I wouldn't mind the "i386" port baseline bumped up to i686-with-SSE2 (and MMX), 
with gcc configured accordingly: I recall some reports that telling gcc to use 
SSE2 really improved several workloads.  But I am fine keeping the status-quo 
of current i686 baseline as well: requiring SSE2 would kick out a non-trivial 
number of non-Intel processor models, I think we went over this the last time a 
"i386" baseline bump was considered.

-- 
  Henrique de Moraes Holschuh 

Re: Pybliographer

[Henrique de Moraes Holschuh]

On Sat, Aug 29, 2020, at 13:11, Ted To wrote:
> Is there any chance of reviving pybliographer?  I understand that it was 
> removed because it relied on old, unsupported Gnome libraries.  But the 
> current version (1.4.0) has removed python-gnome2, python-gnome2-vfs, and 
> python-glade2 dependencies and instead uses pygtk and gettext 
> (https://pybliographer.org/cgi-bin/moin.cgi/News/2018-04-03).  While there 
> are alternatives like jabref and kbibtex, I prefer not to install the java 
> and KDE dependencies.


I recommend you file a RFP bug as described here :
https://wiki.debian.org/RFP

And include the explanation above.

--
  Henrique de Moraes Holschuh 

Re: freepats (was: Re: Intend to remove obsolete debhelper compat levels 5 and 6 before the release of bookworm (bullseye + 1)

[Henrique de Moraes Holschuh]

On Sat, 11 Jul 2020, Henrique de Moraes Holschuh wrote:
> On Sat, 11 Jul 2020, Niels Thykier wrote:
> > This is a heads up about my intention to remove debhelper compat levels
> > 5 and 6.  This is also an intention to do a MFB for this removal now at
> 
> ...
> 
> >freepats
> I will clean it up (switch it to new-style dh) and orphan it.  It is

Done that, and uploaded to unstable.  freepats now uses dh and debhelper
compat level 12.  You can remove freepats from your list.

FWIW, Freepats has been orphaned (#965344) with this upload.  Obviously,
if there are any problems with the cleanup upload, I will deal with it.

-- 
  Henrique Holschuh

freepats (was: Re: Intend to remove obsolete debhelper compat levels 5 and 6 before the release of bookworm (bullseye + 1)

[Henrique de Moraes Holschuh]

On Sat, 11 Jul 2020, Niels Thykier wrote:
> This is a heads up about my intention to remove debhelper compat levels
> 5 and 6.  This is also an intention to do a MFB for this removal now at

...

> Henrique de Moraes Holschuh 
>freepats

Oh wow, I haven't looked at this package seriously for over a decade.

I will clean it up (switch it to new-style dh) and orphan it.  It is
*not* dead upstream but it needs someone that groks .sf2, .pat and
actively uses one of the MIDI renderers enough to actually tweak
soundfonts/patchbanks.

If anyone that likes to tinker around with MIDI wants this package,
please say so: it saves me the effort of orphaning it.

Active upstream is at:
http://freepats.zenvoid.org/index.html
http://freepats.zenvoid.org/SoundSets/general-midi.html

-- 
  Henrique Holschuh

Re: Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[Henrique de Moraes Holschuh]

On Sun, 05 Jul 2020, Andrei POPESCU wrote:
> On Sb, 04 iul 20, 19:56:45, s...@stormbind.net wrote:
> > While fuse-exfat can be coinstalled at any moment exfat-utils and
> > exfatprogs will for now conflict with each other.
> 
> Isn't this the typical use-case for alternatives?

It depends.  Are the CLIs involved compatible?

-- 
  Henrique Holschuh

Re: moving mg from salsa to github?

[Henrique de Moraes Holschuh]

On Sat, 15 Feb 2020, Harald Dunkel wrote:
> I am maintainer for mg, currently on salsa. Problem is, upstream
> doesn't release tar balls anymore, but moved the code to github.
> No tags.
> 
> How can I tell Salsa? Should I drop the upstream and pristine-tar
> branches on Salsa and integrate the repository on github? Would
> you suggest to move the debian part to github instead?

intel-microcode went through this same problem, although it had nothing
to do with salsa.  Suddenly:

1. I had a debian-side upstream branch with full upstream history based
on tarballs that I had built based on tarball-only releases over the
years (make that a decade).

2. I had a new upstream-side upstream branch that would soon accumulate
history, based on their brand new github repo.

And they were two entirely separate trees, of course.  No common origin
commit.

I fixed that using a carefully planned, manually adjusted merge (read
the MERGE STRATEGIES part of the manpage for "git merge", especially the
"ours" and "theirs" of the recursive merge).

That gave me an unified tree that would allow git to do the right thing
as far as future merges, diffs and cherry-picks were concerned.

Obviously, I ensured everything relevant from *both* side of the merges
was present on the merge commit result (and dropped whatever I didn't
want).  The result tree contents MUST be semanthically compatible with
the history it creates, or things will go sour really fast.

>From them on, I just merge from github upstream on a topic branch,
adjust whatever is needed, and then merge the topic branch to master.

Please look at the intel-microcode's history *graph* to undestand what I
mean.  It is on salsa:
https://salsa.debian.org/hmh/intel-microcode

As for tarballs, it really depends.  I'd either generate those using git
based on the upstream's upstream branch, or use the ones from a tagged
github release from upstream, if one exists.

-- 
  Henrique Holschuh

Re: Vital fix to console-common stuck in testing for three months

[Henrique de Moraes Holschuh]

On Mon, 16 Dec 2019, Oskar Berggren wrote:
> This was reported in August 2019 as a grave bug:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935096
> 
> It was fixed early September in 0.7.91 and migrated to testing 2019-09-13:
> https://tracker.debian.org/pkg/console-common
> 
> Sadly, this fix has not yet made it into stable. Is something holding this
> up, or has it just been forgotten?

Fixes only make it to -stable when the maintainer (or another DD)
actually acts on it, prepares a stable upload (s-p-u), and talks to the
stable release manager team to get it approved.

Alastair, are you planning a s-p-u with a fix for 935096?

-- 
  Henrique Holschuh

Re: Programs contain ads - acceptable for packaging for Debian?

[Henrique de Moraes Holschuh]

On Thu, 20 Jun 2019, Samuel Thibault wrote:
> Bagas Sanjaya, le jeu. 20 juin 2019 20:16:08 +0700, a ecrit:
> > On 20/06/19 20.11, W. Martin Borgert wrote:
> > > Quoting Bagas Sanjaya :
> > > > Such ads is displayed only when users have Internet connection, and
> > > > there is no way to patch ZZZ in order to remove ads (or we have to
> > > > buy "pro" version which doesn't contain ads and adds more features).
> > > 
> > > So it's not free software anyway and does not belong to Debian main.
> > > It might be suitable for non-free, but I wonder whether it's worth
> > > the trouble to package it.
> > > 
> > Is it implied that all programs which contain ads are non-free and not
> > suitable for Debian main?
> > 
> > But ZZZ hypothetical package licensed under DFSG-compliant license (such as
> > GPL).
> 
> The concern here is "there is no way to patch ZZZ in order to". If there
> is no way to make the program do what you want, it is not free.

And if there is a [legal, license-compliant] way, but it would raise
major stink with upstream, we don't package it either even if it is
DFSG-compliant.

Not everything that complies to the DFSG is *desirable* in Debian, you
can alwasy package it for your own use, obviously, but don't upload it.

NOTE: unobtrusive, static, non-obnoxious "please donate" messages in a
splash screen at program startup are *NOT* the same as "ad displaying":
we pretty much tolerate such static requests for contributions from
upstream without any fuss.  For one, they're not a security risk, and
also not a privacy risk, unlike anything that downloads advertisements
when it can.

NOTE2: if upstream is fine with the full removal of the advertising
engine and the license allows it then it would be ok to remove it and
upload to Debian with the advertisement engine removed.

-- 
  Henrique Holschuh

Re: Official non-official Debian backporting versioning scheme

[Henrique de Moraes Holschuh]

On Tue, 21 May 2019, Scott Kitterman wrote:
> In Debian we use version-revision (where revision is sometimes complex for 
> backports and stable updates).  If you use version-~revision where revision 
> is 
> some thing similar to, but different than that used for security updates, 
> stable updates, or backports, you could be reasonably assured that your non-
> official version would also sort to a lower revision than the same upstream 
> version from any official repository.

Currently, we do version-revision for packages (unstable),
version-revision~bpo for backports, version-revision+debXuY /
version-revision~debXuY for security and stable-updates (sort higher
than backports, lower than unstable/testing).

If there isn't any reason to mind colisions with backports, just use
~bpo.  It is not like it makes sense to have two "official" (be it
official official or official unofficial :-p ) backports of the same
package.  Whomever comes ladter can just use ~bpoXu2 to superseed the
first backport (~bpoXu1).

That said, there's always "~~bpoXuY", which will sort lower than
anything we use officially.  But you'd need to go around setting bugs as
fixed in version-revision~~ if you integrate with the BTS, etc.

-- 
  Henrique Holschuh

Re: Golang >= 1.12 in Buster?

[Henrique de Moraes Holschuh]

On Mon, 15 Apr 2019, Thomas Goirand wrote:
> On 4/15/19 9:24 AM, Hideki Yamane wrote:
> > On Sun, 14 Apr 2019 21:11:09 +0200
> > "Dr. Tobias Quathamer"  wrote:
> >> I think it's the right decision of the release team to stick with golang
> >> 1.11 for buster. The previous migration from golang 1.10 to 1.11 took us
> >> about four weeks until we had fixed all packages with new FTBFS bugs.
> > 
> >  Can we migrate that from backports -> proposed-updates -> point release?
> 
> Since when do we use backports as a mean to reach Stable?

Well, it can certainly be used as a way to get extra exposure before
proposing a stable-update.  But that's it, AFAIK.

-- 
  Henrique Holschuh

Re: salsa.debian.org maintenance (GitLab 11.1.4 upgrade, external storage migration)

[Henrique de Moraes Holschuh]

On Mon, 13 Aug 2018, Alexander Wirt wrote:
> We don't rely on it. There will be a backup on debian infastructure so that
> we will be able to change to different providers at every time.

...

> But using gce allows us to to support use cases different use case than just
> git (like lfs, build artificats, build logs and so on) without consuming IO
> on debian infrastructure (we are already seeing IO problems on high traffic). 
> 
> Hope that helps

It does.  Thank you very much for doing this!

-- 
  Henrique Holschuh

Bug#904917: general: Gnome randomly crash and restart to login.

[Henrique de Moraes Holschuh]

On Sun, 29 Jul 2018, Riccardo Gagliarducci wrote:
> on Lenovo laptop ideapad 520 Gnome randomly crash and, after some seconds of

Are you using the latest version of the ideapad 520 firmware (BIOS/UEFI
and EC) ?  If not, please upgrade it.

-- 
  Henrique Holschuh

Re: Research survey: Impact of Microsoft Acquisition of GitHub

[Henrique de Moraes Holschuh]

On Fri, 13 Jul 2018, Dominik George wrote:
> > I don't think categorizing these things as spam is the right thing to do
> > -- although ignoring them most of the time is.
> 
> If they don't care enough about privacy and free software before doing a
> survey in a privacy and free software community using privacy and free
> software ignorant tools, it is spam.

That is just your bias (happens to be mine, too).  If their sampling
space is unbiased, a lot of the people in it won't agree with it being a
problem, though.

Unfortunately, the choice of survey tools will bias who will participate
on the survey, so it *is* indeed relevant to the survey results.  But to
unbias it you'd need tools that are neutral on almost every aspect (and
that includes usability by the survey-taking participants, for example).

-- 
  Henrique Holschuh

Re: Systemd dependencies

[Henrique de Moraes Holschuh]

On Mon, 26 Feb 2018, Roberto C. Sánchez wrote:
> On Mon, Feb 26, 2018 at 11:53:27AM +0100, Bastian Blank wrote:
> > On Mon, Feb 26, 2018 at 11:13:03AM +0100, Michael Meskes wrote:
> > > > However I really would start one step before.  What exactly do you
> > > > think
> > > > a service dependency on "mail-transport-agent" does provide you?
> > > Actually it's the other way round. I need my program, clamsmtp, to
> > > start before postfix. I haven't checked with the other MTAs to be
> > > honest. So I guess I could try only adding postfix and see if somebody
> > > reports a problem.
> > 
> > No, this is no reason to introduce such sequence points.  You don't even
> > know that the MTA runs on the same system.
> > 
> Unless it is designed to only interact with an MTA running on the same
> system.

In which case, if it is postfix, you could just ignore it.  It knows to
try again any transports that fail, it knows to do controlled backoff
and all that jazz, does so by default, and has sane defaults even.

But it will pester you in the logs about it, though.

-- 
  Henrique Holschuh

Re: Debian part of a version number when epoch is bumped

[Henrique de Moraes Holschuh]

On Wed, 14 Feb 2018, Vincent Bernat wrote:
>  ❦ 14 février 2018 12:53 +0100, Wouter Verhelst  :
> >> > Would it hurt to take those epoch bumps into Debian?
> >> 
> >> Depends on what you mean by hurt. I see epochs being used w/o much
> >> tought or care, on many situations where they are not supposed to be
> >> used, and they are permanent stigmas.
> >
> > I wonder where this representation of "epoch" as a "stigma" comes from.
> > They're a part of a version number. They're as much a stigma as the "57"
> > in "libavcodec57". What's the big deal? Just use it if you need to, and
> > be done with it.
> >
> > There's really really really nothing wrong with using an epoch. If some
> > of our (or someone else's) infrastructure has issues dealing with them,
> > then that's a bug in the infrastructure and we should fix it. But nobody
> > should be afraid of using an epoch when the upstream version number
> > changes incompatibly, because *that's what they're for*.
> 
> It's not only an infrastructure problem. If you Depends on X (>= 1.8),
> this will be true with X 1:1.6 as well.

Only if your program is severely buggy.

Hint: either it matches dpkg --compare-versions exactly, or it is a
severe bug.

-- 
  Henrique Holschuh

Re: Summary of the 2038 BoF at DC17

[Henrique de Moraes Holschuh]

On Sat, 02 Sep 2017, Steve McIntyre wrote:
> Massive numbers of libraries are going to need updates, possibly more
> than people realise. Anything embedding a time_t will obviously need
> changing. However, many more structures will embed a timeval or
> timespec and they're also broken. Almost anything that embeds
> libc-exposed timing functions will need updating.

Let's not forget about several archive formats, too, such as cpio.  They
have to be extended/replaced.

-- 
  Henrique Holschuh

Re: X facts about Debian - some fact checking and looking for ideas.

[Henrique de Moraes Holschuh]

On Mon, 28 Aug 2017, shirish शिरीष wrote:
> It would be helpful if somebody has one of the 1996 packages snapshots
> and can share how the changelogs were at that point of time. That
> might give a bit of reference as to how things were and if there were
> any changes between them and now.

http://archive.debian.org/debian/pool/main/libc/libc/

Will give you glibc 5, from 1998, but the packaging is from 1999.  It
already had separate changelogs.

> Also the crucial question if whether this idea came in Debian first
> and then flowed to other distributions or was it was first used in
> Redhat and then came to Debian would be interesting in itself.

Sorry, I have no idea about that.  But it is such an obvious thing to do
once you have "distro versions" (which RedHat *already had*), that I'd
bet the dual changelogs came from whomever started with distro-specific
versioning first.

Take a look at early slackware, it is the oldest you can still find.

http://futurist.se/gldt/

-- 
  Henrique Holschuh

Re: Call for volunteers: FTP Team

[Henrique de Moraes Holschuh]

On Thu, 17 Aug 2017, Joerg Jaspert wrote:
> On 14767 March 1977, Jonathan Carter wrote:
> >> it has been quite a while since the last call for volunteers, so here is
> >> an update: Yeah, we still need people, and we want you. Well, that is,
> >> if you are a Debian Developer, for this. If you are not and want to
> >> help, read the last paragraph please.
> > If someone hypothetically joins, are they allowed to rename the FTP team
> > to something that doesn't include "FTP"?
> 
> GopherTeam?

archive team, really.  But where's the fun in that?

funmasters, maybe?  it is only a two-letter change...

-- 
  Henrique Holschuh

Intel Skylake/Kaby Lake Hyper-threading bug update

[Henrique de Moraes Holschuh]

TL;DR: Intel has issued public microcode updates in 2017-07-07, fixing
the hyper-threading errata on every affected processor.  These updates
have been included in the stable and oldstable point releases from
2017-07-22.

The microcode updates in the "intel-microcode" packages with the base
version of 3.20170707.1 fix the hyper-threading defect on every known-
affected Intel processor, including Kaby Lake and all variants of
Skylake.

Updated intel-microcode packages are already available for oldstable,
stable, testing, unstable, jessie-backports-sloppy and
stretch-backports.

For more details and instructions, please refer to:
https://wiki.debian.org/Microcode


FAQ about the "hyper-threading defect":

Q. Does the Intel "microcode update" that fixes the defect remove
   hyper-threading support?

A. The updated microcode *fixes* hyper-threading, it does *not* remove
   hyper-threading support.


Upgraded microcode information related to these errata:

Skylake D0/R0 (mobile/desktop), signatures 0x406e3, 0x506e3:
Known to be fixed in microcode revision 0xb9/0xba and later.  Public fix
available in linux microcode 20170511 and later.

Skylake H0 (server/HEDT/X-series), signature 0x50654:
Known to be fixed in microcode revision 0x222 and later, and it
might have been fixed since revision 0x21a.  Public fix available in
linux microcode 20170707 and later.

Kaby Lake H0/B0 (mobile/desktop), signatures 0x806e9, 0x906e9 (pf mask 0x22):
Known to be fixed in microcode revision 0x5d/0x5e and later.  Public fix
available in linux microcode 20170707 and later.

Kaby Lake X-series, signature 0x906e9 (pf mask 0x08):
These processors are *NOT* affected when installed in a *supported*
motherboard configuration (i.e. one that had its firmware updated to be
compatible with Kaby Lake X-series).  The launch production microcode
already has the fix (believed to be microcode revision 0x5d or later
based on the processor flags mask).

Kaby Lake Y0: signature 0x806ea:
Known to be fixed in microcode revision 0x65/0x66 and later, and it
might have been fixed since revision 0x5d/0x5e. Public fix available in
linux microcode 20170707 and later.


References from the original advisory:

https://caml.inria.fr/mantis/view.php?id=7452
http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_changelog
https://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v6-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v5-spec-update.html
https://www.intel.com/content/www/us/en/products/processors/core/6th-gen-x-series-spec-update.html

New references:

The two new references below contain material that was not known to the
Debian maintainers or to the Debian project:

https://medium.com/ahrefs/skylake-bug-a-detective-story-ab1ad2beddcd
http://gallium.inria.fr/blog/intel-skylake-bug/

-- 
  Henrique Holschuh

Re: Naming of network devices - how to improve it in buster

[Henrique de Moraes Holschuh]

On Sat, 15 Jul 2017, Adam Borowski wrote:
> > This will match any interface that has MAC address 01:23:45:67:89:ab,
> > and will use the "foo" stanzas to configure it.
> 
> Awesome!  This sounds like the best solution so far.

It is indeed Very Cool, but it might not solve one little thing:
iptables firewalling.

Is that a way to trigger an ifrename using this, so that the network
device ends up being named "foo" ?

-- 
  Henrique Holschuh

Re: Naming of network devices - how to improve it in buster

[Henrique de Moraes Holschuh]

On Fri, 14 Jul 2017, Tom H wrote:
> > I've never seen the kernel vary the order it enumerates a PCI bus.

It doesn't, the last time it changed was on 2.4->2.6.

OTOH, *driver probe* ordering can and does change, especially when
device probes are being done in parallel.  It is best to not get bus
enumeration (and even device endpoint enumeration) confused with device
*registration* by kernel drivers.

> For PCI Express; for all I know, other technologies might enumerate
> differently or change the enumeration method with different driver
> versions.

Most buses are stable as far as enumeration goes: we don't have HBAs and
endpoints being renumbered across boots at all for PCI and PCIe and even
USB.

But bus device enumeration is separate from device register ordering.

> Per driver. There's no guarantee that the kernel will load the drivers
> in the same order at boot. There was even a (specific) note in one of

Indeed.  Unless you add modules for which you care about the load order
to /etc/modules.  Those are staticaly loaded first (obeying dependencies
by depmod, though) even by the initramfs.  It has been supported for a
decade or more.

That *still* won't help for some drivers, where parallel *device* probes
are done AND device answer speed mandates which one will register first.
This does *not* apply to PCI/PCIe NICs handled by the same kernel
driver, but it very likely applies to USB for example.

> The classic naming scheme for network interfaces applied by the kernel
> is to simply assign names beginning with "eth0", "eth1", ... to all
> interfaces as they are probed by the drivers. As the driver probing is

Unfortunately, this is incorrect.

MOST PCI/PCIe NICs indeed use "ethX", etc.  But the naming scheme really
is device driver-specific, and the "default" name used by a driver is
considered part of the kernel stable ABI, and cannot be changed on the
kernel side unless it is done opt-in at kernel config time (kconfig) or
at boot time (kernel command line, device tree, etc).

That said, most consumer devices nowadays are handled by drivers that
will use either ethX or wlanX by default.

> generally not predictable for modern technology this means that as soon
> as multiple network interfaces are available the assignment of the names
> "eth0", "eth1" and so on is generally not fixed anymore and it might
> very well happen that "eth0" on one boot ends up being "eth1" on the
> next.

Correct, in the general case.

-- 
  Henrique Holschuh

Re: Naming of network devices - how to improve it in buster

[Henrique de Moraes Holschuh]

On Wed, 12 Jul 2017, Michael Biebl wrote:
> Am 12.07.2017 um 18:58 schrieb Matt Zagrabelny:
> > On Wed, Jul 12, 2017 at 11:47 AM, Michael Biebl  > > wrote:
> > 
> > Am 12.07.2017 um 17:35 schrieb Marc Haber:
> > > My finger memory will still type tcpdump -i eth0 before the brain can
> > > intervene ten years from now.
> > 
> > thankfully tcpdump (and lots of other tools) have nice shell completion.
> > tcpdump -i  works great her.
> > 
> > 
> > Agreed. However, I'd still rather deal with names like /dev/sda and eth0
> > than /dev/disk/by-id/ata-SanDisk_SSD_U100_252GB_122339300522 and en.
> > 
> > It is kind of like using people's first names as opposed to their Social
> > Security Number (in US) or other form of national identification. I know
> > when I can use the name Matt and I know who it refers to, even if
> > another Matt enters the room. I'm comfortable with eth0 being the name,
> > even when another interface appears.
> > 
> > I completely understand, and largely agree with, the need for persistent
> > naming - but I think we are selling ourselves and our users short by not
> > pressing harder for network interface aliases. It seems to be too useful
> > of a solution for this problem.
> 
> Indeed, the best solution would be to never rename the interfaces and
> simply create aliases / symlinks. Then again, I'm no kernel hacker so I
> have no idea if that would be feasible.

ip link set dev eth0 alias foo0

But don't expect everything to work right with this: it is the same
mechanism that was used for adding "extra IP addresses" when using
braindamaged crap from a decade ago (old ifconfig), so I very much bet
there are going to be stuff misbehaving...

The obvious thing would be to just tell the kernel to change namespaces
in the first place (kconfig + command line), and have userspace aware of
the kernel namespace using sysfs.  Just beware the kernel default would
be "unspecified" (and not "eth*", etc) because this is not central
policy in the kernel at all).  I have never understood why this wasn't
done, since it is absolutely trivial to implement, even if it is a lot
of busywork (you have to patch each !@#$ network driver).  But you could
clean up a _LOT_ of crap kernel side while at it, AND create both a
central point for naming this stuff AND better device grouping, so it
would be worth the trouble.  And it would be opt-in, default N, and
detectable from userspace, so that it would not regress anything not
prepared for it.

-- 
  Henrique Holschuh

Re: Corruption in CPU

[Henrique de Moraes Holschuh]

On Tue, 27 Jun 2017, Armin Avdic wrote:
> Hello, I saw your article on corrupted data and I have reason to believe
> that the bad code goes as far back to Intel Pentium D processors, in my

The Intel Pentium D is a very old processor, and its hyper-threading is
very different from the recent processors.  It cannot be the same
defect.

> investigation I have seen that when hyperthreading is disabled the cpu acts
> ok no corrupted data or corrupted downloads however when enabled the
> corrupted data starts showing up and changing md5 completely.

We do ship some public microcode updates for several Pentium D
processors, but they're really old updates.  There is no guarantee that
they will fix your issue.

Note that it could be a problem elsewhere.  Those are old processors, in
old motherboards, with old system components (memory, power supplies,
etc).  And the current software (kernel, etc) is not often tested on
them anymore, so it could be a software problem, too.

If you want to try, please install intel-microcode as described in
https://wiki.debian.org/Microcode

Pentium D specification updates ("defect list"):
https://www.intel.com/content/www/us/en/support/processors/desktop-processors/07016.html
http://www.intel.com/content/dam/support/us/en/documents/processors/pentiumd/sb/310307.pdf
http://www.intel.com/content/dam/support/us/en/documents/processors/pentiumd/sb/306832.pdf

-- 
  Henrique Holschuh

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

[Henrique de Moraes Holschuh]

(updated perl script, it now needs the "liblist-moreutils-perl" package)

On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote:
> On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote:
> > This warning advisory is relevant for users of systems with the Intel
> > processors code-named "Skylake" and "Kaby Lake".  These are: the 6th and
> > 7th generation Intel Core processors (desktop, embedded, mobile and
> > HEDT), their related server processors (such as Xeon v5 and Xeon v6), as
> > well as select Intel Pentium processor models.
> 
> Attached, you will find a perl script that can help detect if your
> system is affected or not.  Many thanks to Uwe Kleine-König for
> suggesting, and writing this script.

Uwe Kleine-König was kind enough to update the perl script to fix the
broken hyper-threading detection.  The new version is attached.

NOTE: You may need to install the liblist-moreutils-perl package for the
script to work.

-- 
  Henrique Holschuh
#!/usr/bin/perl
# Copyright 2017 Uwe Kleine-König
#
# This program is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License version 2 as published by the
# Free Software Foundation.

use List::MoreUtils 'uniq';

open(my $cpuinfo, ") {
	if (/^$/) {
		push @cpus, { %cpu };
		undef %cpu;
	}
	
	$cpu{'cpunum'} = $1 if /^processor\s*:\s(.*)/;
	$cpu{'vendor'} = $1 if /^vendor_id\s*:\s(.*)/;
	$cpu{'family'} = $1 if /^cpu family\s*:\s(.*)/;
	$cpu{'model'} = $1 if /^model\s*:\s(.*)/;
	$cpu{'stepping'} = $1 if /^stepping\s*:\s(.*)/;
	$cpu{'microcode'} = $1 if /^microcode\s*:\s(.*)/;
	$cpu{'core id'} = $1 if /^core id\s*:\s(.*)/;
}

my $num_cpus = @cpus;
my $num_cores = uniq map { $_->{'core id'} } @cpus;

foreach (@cpus) {
	print "cpu " . $_->{cpunum} . ": ";
	if ($_->{'vendor'} eq "GenuineIntel" and $_->{'family'} == 6) {
		my $model = $_->{'model'};
		if ($model == 78 or $model == 94) {
			if ($_->{'stepping'} eq "3") {
my $microcoderev = $_->{'microcode'};
print "Your CPU is affected, ";
if (hex($microcoderev) >= 0xb9) {
	print "but your microcode is new enough\n";
} elsif ($num_cpus == $num_cores) {
	print "but hyper threading is off, which works around the problem\n";
} else {
	print "you should install the latest intel-microcode\n";
}
			} else {
print "You may need a BIOS/UEFI update (unknown Skylake-Y/H/U/S stepping)\n";
			}
		} elsif ($model == 85 or $model == 142 or $model == 158) {
			print "You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)\n";
			print "Note: Kaby Lake X-series processors (i7-7740X, etc) are not affected\n";
		} else {
			print "You're likely not affected\n";
		}
	} else {
		print "You're not affected\n";
	}
}

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

[Henrique de Moraes Holschuh]

(updates, hopefully the last ones...)

On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote:
> Fast-forward a few months, and Mark Shinwell noticed the mention of a
> possible fix for a microcode defect with unknown hit-ratio in the
> intel-microcode package changelog.  He matched it to the issues the
> OCaml community were observing, verified that the microcode fix indeed
> solved the OCaml issue, and contacted the Debian maintainer about it.

There are a few factual incorrections in the advisory text, which were
entirely my fault, and for which I apologise.  The corrections are
below:

1. It was one of the OCaml bug reporters (by the handle of ygrek) who
   first noticed that the 20170511 microcode update could be relevant,
   and not Mark Shinwell.

2. Various other bug reporters and OCaml developers, some under request
   from Mark and some by their own volition, helped out and devoted
   substantial time to investigating the issue.

I apologise to those involved: to "ygrek" for misreading the bug report
and attributing to Mark Shinwell the correlation between the SKL150
erratum description and the OCaml compiler issue report; and to all
members of the OCaml community that worked on the issue both in the bug
report and behind the scenes, for not explicitly crediting their effort.

The original OCaml bug report is listed in the references section at the
end of the advisory (and also in this update).

> Related processor signatures and microcode revisions:
> Skylake   : 0x406e3, 0x506e3 (fixed in revision 0xb9/0xba and later,
>   public fix in linux microcode 20170511)
> Skylake   : 0x50654  (no information, erratum listed)
> Kaby Lake : 0x806e9, 0x906e9 (defect still exists in revision 0x48,
>   fix available as a BIOS/UEFI update)

The recently launched "Kaby Lake-X" processors (signature 0x906e9,
socket LGA2066) are documented by Intel as *NOT* being affected by the
KBL095 defect.  This information comes from table 16 of the latest
revision of the "7th gen. Core Family specification update" (which is
listed in the references section).

Please note that the "7th gen. Core i7 X-series processors" (Kaby
Lake-X) both support hyper-threading and share the processor signature
(family, model number and stepping) with "Kaby Lake-H/S" processors.
The tests in the advisory (and also the perl script) will *incorrectly*
report Kaby Lake-X processors as affected.

References:
https://caml.inria.fr/mantis/view.php?id=7452
http://metadata.ftp-master.debian.org/changelogs/non-free/i/intel-microcode/unstable_changelog
https://www.intel.com/content/www/us/en/processors/core/desktop-6th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/core/7th-gen-core-family-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v6-spec-update.html
https://www.intel.com/content/www/us/en/processors/xeon/xeon-e3-1200v5-spec-update.html
https://www.intel.com/content/www/us/en/products/processors/core/6th-gen-x-series-spec-update.html

-- 
  Henrique Holschuh

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

[Henrique de Moraes Holschuh]

On Mon, 26 Jun 2017, Holger Levsen wrote:
> Are there any other public bug reports which got fixed by this, or is the
> ocaml issue the only known issue which gets fixed by installing this microcode
> update?

As far as I know, so far OCaml is the only one that was verified to be
caused by the SKL150 erratum.

I got some comments about the advisory after it was published.  According
to a couple of those, the code pattern that triggers SKL150 is one that
is usually avoided [by compilers and hand-optimized assembly] due to
performance reasons.  Apparently, it is explicitly documented as being
slow by Intel optimization manuals.

That may well mean the pattern is rare enough that nothing else in
Debian is affected.

-- 
  Henrique Holschuh

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

[Henrique de Moraes Holschuh]

Minor update on the issue:

The check command provided in the advisory to test for hyper-threading
doesn't work: it will always report hyper-theading as enabled.  A better
command is provided below.

Note: this also means the perl script will give some false-positives.
I apologise for the inconvenience.


On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote:
> Once you know your processor model name, you can check the two lists
> below:
> 
>   * List of Intel processors code-named "Skylake":
> http://ark.intel.com/products/codename/37572/Skylake
> 
>   * List of Intel processors code-named "Kaby Lake":
> http://ark.intel.com/products/codename/82879/Kaby-Lake
> 
> Some of the processors in these two lists are not affected because they
> lack hyper-threading support.  Run the command below in a command line
> shell (e.g. xterm), and it will output a message if hyper-threading is
> supported/enabled:
> 
>   grep -q '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo && \
>   echo "Hyper-threading is supported"

The above test (using "grep") does not work, and will always report that
hyper-threading is enabled.

Please use the "lscpu" utility from the util-linux package in a command
line shell (e.g.  xterm):

lscpu

If the lscpu output reports: "Thread(s) per core: 2", that means
hyper-threading is enabled and supported.

If the lscpu output reports: "Thread(s) per core: 1", that means
hyper-threading either disabled or not supported.  In this case, the
specific defect mentioned in the advisory will not trigger.

-- 
  Henrique Holschuh

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

[Henrique de Moraes Holschuh]

For the record: the email with the perl script doesn't contain malware.

The "malware" alert came from an extremely badly configured system that
violates every best practice in the field: it sends email to every
original recipient (and not just to local users), and it FORGES its
headers to look like it was sent by the original sender.

-- 
  Henrique Holschuh


signature.asc
Description: Digital signature

Re: [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

[Henrique de Moraes Holschuh]

On Sun, 25 Jun 2017, Henrique de Moraes Holschuh wrote:
> This warning advisory is relevant for users of systems with the Intel
> processors code-named "Skylake" and "Kaby Lake".  These are: the 6th and
> 7th generation Intel Core processors (desktop, embedded, mobile and
> HEDT), their related server processors (such as Xeon v5 and Xeon v6), as
> well as select Intel Pentium processor models.

Attached, you will find a perl script that can help detect if your
system is affected or not.  Many thanks to Uwe Kleine-König for
suggesting, and writing this script.

-- 
  Henrique Holschuh
#!/usr/bin/perl
# Copyright 2017 Uwe Kleine-König
#
# This program is free software; you can redistribute it and/or modify it under
# the terms of the GNU General Public License version 2 as published by the
# Free Software Foundation.

open(my $cpuinfo, ") {
	if (/^$/) {
		print "cpu $cpunum: ";
		if ($vendor eq "GenuineIntel" and $family == 6) {
			if ($model == 78 or $model == 94) {
if ($stepping eq "3") {
	print "Your CPU is affected, ";
	if (hex($microcoderev) >= 0xb9) {
		print "but your microcode is new enough\n";
	} elsif ($hyperthreading ne "on") {
		print "but hyper threading is off, which works around the problem\n";
	} else {
		print "you should install the latest intel-microcode\n";
	}
} else {
	print "You may need a BIOS/UEFI update (unknown Skylake-Y/H/U/S stepping)\n";
}
			} elsif ($model == 85 or $model == 142 or $model == 158) {
print "You may need a BIOS/UEFI update (Kaby Lake, or Skylake-X processor)\n";
			} else {
print "You're likely not affected\n";
			}
		} else {
			print "You're not affected\n";
		}

		$cpunum = undef;
		$vendor = undef;
		$family = undef;
		$stepping = undef;
		$microcoderev = undef;
		$hyperthreading = undef;

		next;
	}

	$cpunum = $1 if /^processor\s*:\s(.*)/;
	$vendor = $1 if /^vendor_id\s*:\s(.*)/;
	$family = $1 if /^cpu family\s*:\s(.*)/;
	$model = $1 if /^model\s*:\s(.*)/;
	$stepping = $1 if /^stepping\s*:\s(.*)/;
	$microcoderev = $1 if /^microcode\s*:\s(.*)/;

	if (/^flags\s*:/) {
		if (/^flags\s*:.*\bht\b/) {
			$hyperthreading = "on";
		} else {
			$hyperthreading = "off";
		}
	}
}

[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading

[Henrique de Moraes Holschuh]

This warning advisory is relevant for users of systems with the Intel
processors code-named "Skylake" and "Kaby Lake".  These are: the 6th and
7th generation Intel Core processors (desktop, embedded, mobile and
HEDT), their related server processors (such as Xeon v5 and Xeon v6), as
well as select Intel Pentium processor models.

TL;DR: unfixed Skylake and Kaby Lake processors could, in some
situations, dangerously misbehave when hyper-threading is enabled.
Disable hyper-threading immediately in BIOS/UEFI to work around the
problem.  Read this advisory for instructions about an Intel-provided
fix.


SO, WHAT IS THIS ALL ABOUT?
---

This advisory is about a processor/microcode defect recently identified
on Intel Skylake and Intel Kaby Lake processors with hyper-threading
enabled.  This defect can, when triggered, cause unpredictable system
behavior: it could cause spurious errors, such as application and system
misbehavior, data corruption, and data loss.

It was brought to the attention of the Debian project that this defect
is known to directly affect some Debian stable users (refer to the end
of this advisory for details), thus this advisory.

Please note that the defect can potentially affect any operating system
(it is not restricted to Debian, and it is not restricted to Linux-based
systems).  It can be either avoided (by disabling hyper-threading), or
fixed (by updating the processor microcode).

Due to the difficult detection of potentially affected software, and the
unpredictable nature of the defect, all users of the affected Intel
processors are strongly urged to take action as recommended by this
advisory.


DO I HAVE AN INTEL SKYLAKE OR KABY LAKE PROCESSOR WITH HYPER-THREADING?
---

The earliest of these Intel processor models were launched in September
2015.  If your processor is older than that, it will not be an Skylake
or Kaby Lake processor and you can just ignore this advisory.

If you don't know the model name of your processor(s), the command below
will tell you their model names.  Run it in a command line shell (e.g.
xterm):

grep name /proc/cpuinfo | sort -u

Once you know your processor model name, you can check the two lists
below:

  * List of Intel processors code-named "Skylake":
http://ark.intel.com/products/codename/37572/Skylake

  * List of Intel processors code-named "Kaby Lake":
http://ark.intel.com/products/codename/82879/Kaby-Lake

Some of the processors in these two lists are not affected because they
lack hyper-threading support.  Run the command below in a command line
shell (e.g. xterm), and it will output a message if hyper-threading is
supported/enabled:

  grep -q '^flags.*[[:space:]]ht[[:space:]]' /proc/cpuinfo && \
echo "Hyper-threading is supported"

Alternatively, use the processor lists above to go to that processor's
information page, and the information on hyper-threading will be there.

If your processor does not support hyper-threading, you can ignore this
advisory.


WHAT SHOULD I DO IF I DO HAVE SUCH PROCESSORS?
--

Kaby Lake:

Users of systems with Intel Kaby Lake processors should immediately
*disable* hyper-threading in the BIOS/UEFI configuration.  Please
consult your computer/motherboard's manual for instructions, or maybe
contact your system vendor's support line.

The Kaby Lake microcode updates that fix this issue are currently only
available to system vendors, so you will need a BIOS/UEFI update to get
it.  Contact your system vendor: if you are lucky, such a BIOS/UEFI
update might already be available, or undergoing beta testing.

You want your system vendor to provide a BIOS/UEFI update that fixes
"Intel processor errata KBL095, KBW095 or the similar one for my Kaby
Lake processor".

We strongly recommend that you should not re-enable hyper-threading
until you install a BIOS/UEFI update with this fix.


Skylake:

Users of systems with Intel Skylake processors may have two choices:

1. If your processor model (listed in /proc/cpuinfo) is 78 or 94, and
   the stepping is 3, install the non-free "intel-microcode" package
   with base version 3.20170511.1, and reboot the system.  THIS IS
   THE RECOMMENDED SOLUTION FOR THESE SYSTEMS, AS IT FIXES OTHER
   PROCESSOR ISSUES AS WELL.

   Run this command in a command line shell (e.g. xterm) to know the
   model numbers and steppings of your processor.  All processors must
   be either model 78 or 94, and stepping 3, for the intel-microcode fix
   to work:

 grep -E 'model|stepping' /proc/cpuinfo | sort -u

   If you get any lines with a model number that is neither 78 or 94, or
   the stepping is not 3, you will have to disable hyper-threading as
   described on choice 2, below.

   Refer to the section "INSTALLING THE MICROCODE UPDATES FROM NON-FREE"
   for instructions on how to install the intel-microcode package.

2. For other processor

Re: Please add lzip support in the repository

[Henrique de Moraes Holschuh]

On Fri, 16 Jun 2017, Adrian Bunk wrote:
> On Thu, Jun 15, 2017 at 08:36:48PM -0300, Henrique de Moraes Holschuh wrote:
> >...
> > We pretty much need Debian packages to be 100% correct in the first
> > place, they are not going to be subject to lossy recovery from
> > corruption (which is where lzip is supposed to be much better than xz):
> > we need to replace any that is even slightly corrupt with a fully
> > correct copy.
> > 
> > So, it would make more sense to have a par2 (or create a modern version
> > of it, actually) ECC layer on top of the compression layer, at which
> > point we can use one of the already supported compression formats.
> >...
> 
> A digital signature is an ECC layer.

ECC as in eliptic-curve crypto?  That's useless for repair.

It should have been obvious by context, especially since I even
mentioned "par2", but it was ECC as in Error-Correcting Code.

https://en.wikipedia.org/wiki/Error-correcting_code

-- 
  Henrique Holschuh

Re: Please add lzip support in the repository

[Henrique de Moraes Holschuh]

On Thu, 15 Jun 2017, mariabi...@gmail.com wrote:
> PS: lzip version available in Debian is 1.16, but the last one is 1.19. Maybe 
> it's time to update! :)

lzip 1.19 is available just in Debian experimental, because we are in
final-countdown nearly-absolute freeze: we will release the next Debian
stable this weekend, with lzip 1.18.

lzip 1.19 should be uploaded to Debian unstable sometime after we
release, at its debian maintainer discretion.

-- 
  Henrique Holschuh

Re: Please add lzip support in the repository

[Henrique de Moraes Holschuh]

On Thu, 15 Jun 2017, Christoph Biedl wrote:
> Also I doubt the reduced disk space and network bandwitdth usage of any
> new kid on the block (there's also zstd) really justifies the work
> needed to implement the support in the many tools that deal with the
> files. I might be convinced otherwise.

I agree with almost everything you said, but the whole point of using
lzip instead of xz would be for a less fragile on-disk format, not
performance (be it speed, memory usage, or compression ratio).

And I don't think we actually benefit any from a less fragile compressed
container format for Debian *packages* (source or binary).

We pretty much need Debian packages to be 100% correct in the first
place, they are not going to be subject to lossy recovery from
corruption (which is where lzip is supposed to be much better than xz):
we need to replace any that is even slightly corrupt with a fully
correct copy.

So, it would make more sense to have a par2 (or create a modern version
of it, actually) ECC layer on top of the compression layer, at which
point we can use one of the already supported compression formats.

And the same is also very likely true for data you hold dear.  par2 ECC
information will allow you to recover from much worse file damage than
lzip's better format ever could.

Now, if a lot of upstream tarballs start to be natively avaiable in .gz
and .lzip format (no .xz), *then* it becomes interesting to at least
support lzip for source packages.

-- 
  Henrique Holschuh

Re: Too many Recommends (in particular on mail-transport-agent)

[Henrique de Moraes Holschuh]

On Mon, 12 Jun 2017, Anthony DeRobertis wrote:
> Of course—for the under 100K being saved here, only Rube Goldberg would
> approve.

It is a bit less than 1MiB saved on an AMD system when you purge
intel-microcode, but even that is likely to not be considered worth the
cost of the extra (empty) cpu-microcode-all package.

Besides, it is not like these packages waste valuable resources when
installed on a system they don't support, either: by default, once
installed, they detect the processor vendor and go inactive when it
doesn't match the one they are for.

That said, if anyone provides a compelling reason to switch to the
cpu-microcode-all + virtual cpu-microcode scheme (as in: give examples
of how the behavior changes on widely used package managers), and gets
the buy-in from the firmware-nonfree package, I will deploy it for
amd64-microcode and intel-microcode.

-- 
  Henrique Holschuh

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Henrique de Moraes Holschuh]

On Sun, 11 Jun 2017, Sean Whitton wrote:
> Henrique de Moraes Holschuh  writes:
> 
> > Not just that.  If it is for NMUs, one also has to ensure it matches
> > what got uploaded (regardless of method: NMU patch, PR, branch...).
> 
> I'm not sure what you're getting at here -- this DEP is for changes that
> *aren't* to be uploaded as part of an NMU.

The (thread?) naming is unfortunate, then.  Anyway, if it does not
involve NMUs, my comment does not apply.

-- 
  Henrique Holschuh

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Henrique de Moraes Holschuh]

On Fri, 09 Jun 2017, Tollef Fog Heen wrote:
> > Per the DEP:
> > 
> > > it is very useful for a maintainer to know that a change has been
> > > approved by someone who has been trusted by the project with the
> > > technical ability to NMU the package
> > 
> > This would be much more cumbersome to achieve with PRs.
> 
> I'm not sure why this is very useful.  It can, in some cases, be a
> useful data point, but in general, as the maintainer, I'll want to
> review the patch in the same way no matter whether it came from somebody
> with a key in the keyring or not.

Not just that.  If it is for NMUs, one also has to ensure it matches
what got uploaded (regardless of method: NMU patch, PR, branch...).

-- 
  Henrique Holschuh

Re: Switch default installation image link?

[Henrique de Moraes Holschuh]

On Tue, 06 Jun 2017, Adam Borowski wrote:
> No one installs i386 new -- machines that are non-amd64-capable are:
> * mainstream machines from 2004 and earlier

That date is incorrect.  I can't give you a precise date, but the
Thinkpad T43 with a 32-bit Centrino Pentium-M was **launched** in
April/2005.

And I am pretty sure there were several 32-bit only processors after the
Pentium-M, including several Atom-based systems that either didn't
support, or had 64-bit mode disabled in BIOS because it was just too
damn slow.

So, no earlier than 2008.

-- 
  Henrique Holschuh

Re: Too many Recommends (in particular on mail-transport-agent)

[Henrique de Moraes Holschuh]

On Fri, 02 Jun 2017, Anthony DeRobertis wrote:
> On 06/01/2017 01:00 PM, Henrique de Moraes Holschuh wrote:
> >Anything on the top three priorities (critical, alert and emergency) is
> >supposed to be displayed immediately to all logged-in users (including
> >remote ones), no matter what.
> 
> Only LOG_EMERG does that, at least on my machine and I'm pretty sure that's
> the default rsyslog config. Unfortunately, a RAID member failure is only
> legitimately LOG_ALERT. Sort of a moot point though...

Hmm, true.  I misrecalled this detail and failed to check it to be
correct before posting.

We should consider changing that to at least include ALERT as well.

> >>It would be great it we had an alert program to use instead of email
> >KDE displays high-priority system alerts as high priority notifications
> >by default (maybe some of it because of the default configuration of
> >rsyslog).
> 
> Running KDE here, so familiar with them. The first problem with those is
> they automatically vanish after a few seconds. They remain around, if you
> pull up the alert notifier, but that little (1) in the systray is easy to
> miss.

Yes.  I just tested it in Debian stable with "logger -p EMERG
this_is_only_a_test".

It would be far better if KDE used the (!) pictogram at least for ALERT
and EMERG priorities, but it seems to be getting the messages from the
ttys instead of from journald or the syslog daemon.  I did not test this
throughoutly, though.

And yes, I stand corrected. It does not display ALERT or CRIT priorities
by default, only EMERG.  Which is Not Good Enough as far as I am
concerned.

> Second problem is that only works if you're logged in. Even on a typical
> desktop where the main user is the admin, it's not safe to assume a that
> user will always be logged in:

Well, yes.  Remote syslog (wherever deployed) will receive the messages
quasi-real-time, though.  And the messages *are* going to be recorded on
the journal and /var/log/syslog.

Whether someone will read the logs or not, well... it is the same issue
with notifications over local email to root: one has to assume the
system has been properly configured as an Unix workstation (and thus it
has local email routing that goes somewhere it will be read).

I am for doing the three by default: email (for stuff like mdadm),
proper syslog or journald (for everything), and proper desktop-
environment notifications for whomever is logged in.

>  * Turn on machine, go grab coffee or tea while it's booting. Disk
>failure occurs before you get back and log in.

In the older days, you'd have the messages on the login tty, even if it
screwed up the graphical screen (Solaris and Sun-OS style ;p).

Or you'd have a xconsole window open, even on the xdm screen (which I
never tried to do, I wonder if this was a local xdm change...)

-- 
  Henrique Holschuh

Re: Too many Recommends (in particular on mail-transport-agent)

[Henrique de Moraes Holschuh]

On Thu, 01 Jun 2017, Anthony DeRobertis wrote:
> On May 31, 2017 3:51:33 AM EDT, Simon McVittie 
>  wrote:
> >Can't it report this via the system log? (syslog, systemd-journald)
> 
> The kernel already does, but of course the system log has a lot of
> messages, every several seconds on some systems. And the systemd
> journal can be even worse, volume-wise. 

The kernel log, syslog, and the journal... all of them have the idea of
message priorities.

Anything on the top three priorities (critical, alert and emergency) is
supposed to be displayed immediately to all logged-in users (including
remote ones), no matter what.

> It would be great it we had an alert program to use instead of email

KDE displays high-priority system alerts as high priority notifications
by default (maybe some of it because of the default configuration of
rsyslog).

rsyslog will forcefully write high-priority messages to all ttys, local
and remote, by default.

If your DE doesn't display system alerts by default, it is a fight you
might want to take... file bugs!

> discussed before... If we had one, it'd be relatively easy to have
> mdadm, smartmontools, etc. use it. 

We have had this working for the better part of two decades, through
syslog.  We also have had an extremely good daemon to take care of it
for nearly half that time: rsyslog.  And rsyslog is configured to do the
right thing by default.

Since journald can plug to syslog just fine, and does so by default in
Debian, it also does the right thing by default at least in Debian.

What we *might* not do by default is to force all the DEs to display
these alerts out-of-the-box.  I haven't tested all main DEs for this, so
I wouldn't know.

> >> OTOH, seems weird for Dracut to recommend mdadm. Surely a system
> >> booting from RAID would already have it installed?
> >
> >dracut defaults to creating a general-purpose initramfs that is not
> >meant to hard-code anything and can be used to boot "most" hardware 
> 
> I'm not really familiar with Dracut, but I'll note that needing mdadm
> is almost always a property of the OS install being booted, not of the
> hardware it's running on. So not including mdadm doesn't make the
> particular install any less portable, though it does make the
> initramfs less general to booting arbitrary installs.

Correct.

The initramfs-tools does not depend or recommend mdadm.  However,
initramfs-tools is modular and its mdadm support is supplied by the
mdadm package.

Dracut isn't modular, and its mdadm support is built-in.  This is a key
difference.

One needs to actually read dracut's source code to know how it would
behave in all boundary conditions related to mdadm support, in which
case it might only suggest or not even mention mdadm.  It probably is
safe, but the point is that someone has to check it first.

-- 
  Henrique Holschuh

Re: Too many Recommends (in particular on mail-transport-agent)

[Henrique de Moraes Holschuh]

On Wed, 31 May 2017, Adam Borowski wrote:
> Thus, axing this dependency or degrading it to Suggests would be probably a
> good idea.  And there's hundreds if not thousands of Recommends of this kind
> that need to be looked at -- this example is just more prominent as it
> affects every Debian system.
> 
> (I'm not filing bugs yet as it's better to have a consensus first before
> mass-filing.)

It is being done on a per-case basis, isn't it?  Like you described the
libuid versus uuid-runtime?

So, it is not a mass-filing, and it is OK.  Just file the bugs one by
one, with your reasoning, and tag them with usertags if you want to
control them as an unit or something.

A mass-filing for this (the exact oposite of studying each recommends in
a case-by-case basis) _IS_ going to cause imense pushback.  I recommend
against it ;-)

-- 
  Henrique Holschuh

Re: Machine Parsable Release Information Specification

[Henrique de Moraes Holschuh]

On Fri, 05 May 2017, Benjamin Drung wrote:
> I am sending this mail to the development list of the distributions
> CentOS, Debian, Fedora, openSUSE and Ubuntu. I am working for
> ProfitBricks and we provide public images in our cloud for these
> distributions.
> 
> Currently I know no way to retrieve the release information about
> new/updated ISO and disk images in a machine parsable and secure way.
> Instead I have to visit the websites and collect the information
> manually.
> 
> My idea is to create a (simple) image release information specification
> and let every distribution provide one release file which accessible
> via https or gpg signed. I created an initial draft of the spec:
> https://github.com/bdrung/image-release-spec
> 
> Your thoughts? Does it make sense? Is the information already provided
> somewhere else?

Attempting to preempt the creation of a Massive Cross-post Thread from
Hell...

PLEASE open an issue or pull request at the above mentioned github
project to discuss and suggests changes to that specification, instead
of doing it over four *very large* mailing lists.

Thank you ;-)


PS: I am reading said spec right now.  If I have any comments, I will
either register an issue, or submit a pull request with proposed
changes...

-- 
  Henrique Holschuh

Re: policy for shipping sysctl.d snippets in packages?

[Henrique de Moraes Holschuh]

On Sun, 23 Apr 2017, Evgeni Golov wrote:
> Both, procps and systemd support (/usr)?/lib/sysctl.d/*.conf, however only
> one package (systemd-coredump) uses it, all others drop files in
> /etc/sysctl.d.

Please drop it in /etc, debhelper/dh should mark it as conffile and
everything will work.

Alternatively, use ufc (refer to ucf(1) and its documentation if you are
not used to ucf.  Help is also available at debian-mentors@l.d.o), and
handle it as a configuration file in /etc managed through ucf and
package maintainer scripts.

> Some packages also trigger "sysctl -q -p " in their postinst, but
> most do not.

What to do here is decided on a case-by-case basis, I suppose.

> My gut feeling is that droping the file to /usr/lib and allowing the admin
> to override it later via /etc. And then load it in postinst.

Drop it in /etc where it belongs, and let the maintainer to modify or
override (by deleting, even).

Leave the /usr/lib overriden by /etc thing alone.

> But this does not account for the fact that this specific tunable may be
> already overriden in another sysctl.d file and the package would reset
> it to a lower value?

Yes.  If you use ucf instead of the builtin dpkg conffile management,
you can do something much better:


1. read current levels (using sysctl, not directly).

2. if they are above the default, don't change the state of the system:
   if your config file is there, let ucf handle its update normally.  if
   your config file is *NOT* there, assume deleted and help ucf a little
   (ucf can do this by itself most of the time: we have always handled
   deletion of config files in /etc as an action to be preserved, but
   *not* at first install)

3. if they are at a dangerous level, install your config file to /etc
   normally, using ucf.  And document that the user needs to reboot
   somewhere.

The above is a rough idea.  You are likely to also have to have
different paths for initial install and upgrade/downgrade.  And if you
actually activate the new sysctl, you might not be able to do (1) that
way should it would break indepondence (and complexity would go up a
great deal).

-- 
  Henrique Holschuh

Re: changelog practice, unfinalised vs UNRELEASED vs ~version

[Henrique de Moraes Holschuh]

On Tue, Feb 14, 2017, at 19:42, Ian Jackson wrote:
> Simon McVittie writes ("Re: changelog practice, unfinalised vs UNRELEASED
> vs ~version"):
> > On Mon, 13 Feb 2017 at 09:42:32 +1100, Ben Finney wrote:
> > > I don't see how this complaint is any different from the need to merge,
> > > for example, changes to API documentation and test cases that accompany
> > > a functional change.
> > 
> > It's the difference between "sometimes conflicts" and "always conflicts".
> 
> This is a very real problem for debian/changelog, but mergechangelogs
> helps a lot.  In any case as I say I'm not trying to mandate the

Usable VCSes have pluggable merge drivers, and there are such drivers
for both GNU-style ChangeLog, and debian/changelog[1].  IME, they "just
work".  So, yeah, one *can* have the chagelog-update-along-with-change
workflow sanely most of the time nowadays.  

I would never use such an workflow unless forced, as I believe the
"proper commit log Tao" is better in the long run, and when your commit
logs are proper (and quite verbose), the natural workflow [2] asks for
changelog-updating commits before release (or maybe at the tip of every
ready-for-integration branch, etc), but...

[1] refer to dpkg-mergechangelogs(1) for the git driver for
debian/changelog, for example.

[2] as in "less busywork" while hacking, and no weird (and possibly
maintenance-hell-creating) disparity from commit log contents to in-tree
changelog contents.

-- 
  Henrique de Moraes Holschuh 

Re: manpages.debian.org has been modernized!

[Henrique de Moraes Holschuh]

On Wed, 18 Jan 2017, Michael Stapelberg wrote:
> https://manpages.debian.org has been modernized! We have just launched
> a major update to our manpage repository. What used to be served via a
> CGI script is now a statically generated website, and therefore
> blazingly fast.

Oooh, nice! A big thank you for all involved!

> Much like the Debian package tracker, manpages.debian.org includes
> packages from Debian oldstable, oldstable-backports, stable,
> stable-backports, testing and unstable. New manpages should make their
> way onto manpages.debian.org within a few hours.

Maybe you could consider adding the manpages from packages in contrib as
well?  Unlike non-free, the licenses in contrib are all compatible with
the DFSG, so they must not have any license restrictions that would get
in the way...

-- 
  Henrique Holschuh

Re: Installing missing conffiles (was Re: dpkg no longer installs conffiles??)

[Henrique de Moraes Holschuh]

On Wed, 30 Nov 2016, Guillem Jover wrote:
> On Tue, 2016-11-29 at 19:18:41 +0100, Simon Richter wrote:
> > To force reinstallation of configuration files, invoke dpkg with the
> > "--force-confmiss" option when installing. This will only restore
> > missing configuration files, but not overwrite changed ones. If some
> > configuration files were damaged, you can use "--force-confnew" to
> > unpack all configuration files; your old files can be found with a
> > ".dpkg-old" suffix then.
> 
> This is I guess, an extended misconception, --force-confmiss will only
> install missing conffiles if they are missing AND the conffile changes
> in the new package relative to the one installed (as documented in the
> man page).
> 
> What you probably want is --force-confask --force-confmiss.

Please document this as an example in the manpage?

-- 
  Henrique Holschuh

Re: Difference in behaviour between pbuilder and sbuild

[Henrique de Moraes Holschuh]

On Mon, Nov 28, 2016, at 11:09, Johannes Schauer wrote:
> If you really somehow export DH_ALWAYS_EXCLUDE somewhere, then the reason

Then that package is subtly broken :-)

When one needs DH_ALWAYS_EXCLUDE for a build to work, that's fine: it is
there to be used...  but it has to be set and exported inside
debian/rules.

-- 
  Henrique de Moraes Holschuh 

Re: OpenSSL 1.1.0

[Henrique de Moraes Holschuh]

On Thu, 24 Nov 2016, Adrian Bunk wrote:
> On Wed, Nov 23, 2016 at 11:50:12PM -0200, Henrique de Moraes Holschuh wrote:
> > On Thu, 24 Nov 2016, Kurt Roeckx wrote:
> >...
> > > > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> > > > might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> > > > says "use SSL", etc), then it should be fine.
> > > 
> > > It seems to be doing this in qtbase5-private-dev. Not sure if
> > > there are actually any users of it.
> > 
> > If it does, all reverse *build* dependencies would need to be inspected,
> > then.
> > 
> > AFAIK, that means they must not link to anything that could link to a
> > different libssl than the one used by qt5.  If they do, everything needs
> > to be inspected down to the details to ensure nothing will ever leak
> > openssl contextes and data structures across a library boundary
> > (including the application).
> 
> If inspection is not easily possible, then adding a dependency on 
> libssl1.0-dev to qtbase5-private-dev should be sufficient to
> ensure that this is not leaked to a different OpenSSL version.

How so? 

Consider the flattened tree (app is the root, - denotes a branch).

A - B - App -  C - D

Where A and D are two versions of openssl. B and C are libs (suppose B
comes from qtbase5-private-dev) from different source packages.

-- 
  Henrique Holschuh

Re: OpenSSL 1.1.0

[Henrique de Moraes Holschuh]

On Thu, 24 Nov 2016, Kurt Roeckx wrote:
> I've always had the impression that there are or used to be
> probems using using dlopen()/dlsym(). Maybe related to some things
> like RTDL_GLOBAL that causes the symbol lookup to go to the wrong
> library. Do you know of any problems related to that?

AFAIK, OpenSSL itself -- at least as packaged by Debian -- should not
get confused about where its *own* static globals are.  And any globals
it might export would also be fully ELF-symbol-versioned from what I can
see (objdump -tT).

If RTDL_GLOBAL is borking ELF symbol versioning, all bets are off.

Note: I have no idea what happens if you throw libssl.a into the mix
with a different version of libssl.so.  This kind of hell-born
braindamage can happen due to glibc nss modules, for example.

> Note that QT is one of those that uses dlopen()/dlsym() when
> calling openssl functions (for license reasons).

No comment I could make about this would be acceptable in polite
company.  Or in impolite company.  Or even during a sailor-class-cursing
competition.

> > So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
> > might not be safe.   If it doesn't (i.e. at most you have a qt flag that
> > says "use SSL", etc), then it should be fine.
> 
> It seems to be doing this in qtbase5-private-dev. Not sure if
> there are actually any users of it.

If it does, all reverse *build* dependencies would need to be inspected,
then.

AFAIK, that means they must not link to anything that could link to a
different libssl than the one used by qt5.  If they do, everything needs
to be inspected down to the details to ensure nothing will ever leak
openssl contextes and data structures across a library boundary
(including the application).

-- 
  Henrique Holschuh

Re: OpenSSL 1.1.0

[Henrique de Moraes Holschuh]

On Mon, Nov 21, 2016, at 11:06, Jan Niehusmann wrote:
> On Mon, Nov 21, 2016 at 11:11:09AM +0100, Tino Mettler wrote:
> > At the end I noticed that Qt will stay at 1.0 (by glancing into the
> > changelog of the relevant upload) which means that my package also has
> > to to stay at 1.0 and the whole excitement resulted in just a changed
> > build-dep.
> 
> I'm not so sure about this any more:
> 
> In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=844018 Stepan
> Golosunov wrote that according to his understanding of dlsym(3), it
> should be fine to link a program with OpenSSL 1.1 and Qt at the same
> time, even though Qt links to OpenSSL 1.0.
> 
> Can somebody who knows OpenSSL, Qt and dlopen/dlsym well enough confirm
> that?

The linking is fine, I believe even any eventual globals (if any) will
be correctly handled in Debian nowadays.  What causes extremely nasty
issues is layering violations causing openssl data structures to leak
from something linked to one version of the library, to something else
linked to another version of the library.

 If, at any point, internal data structures from openssl are exposed, or
 OpenSSL contextes are passed between two libraries, or a library and an
 application, *they must all be from the same openssl*.

This is not something the linker or dlopen/dlsym can enforce.  And you
need to manually inspect the code to be sure... usually.

So, if Qt *ever* exposes its use of openssl anywere in its APIs, it
might not be safe.   If it doesn't (i.e. at most you have a qt flag that
says "use SSL", etc), then it should be fine.

-- 
  Henrique de Moraes Holschuh 

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Thu, Nov 17, 2016, at 12:12, Adrian Bunk wrote:
> On Thu, Nov 17, 2016 at 11:38:46AM -0200, Henrique de Moraes Holschuh
> wrote:
> > On Thu, Nov 17, 2016, at 09:50, Adrian Bunk wrote:
> > > But we do already have > 1 year of widespread testing by users
> > > running unstable/testing on machines with TSX enabled.
> > > 
> > > So for unstable/stretch this does not seem to be a huge problem.
> > > 
> > > These are normal bugs that should be found and fixed if possible,
> > > just like passing a pointer in an int or many other kinds of bugs.
> > > 
> > > Or do I miss anything here?
> > 
> > I am not sure we have that much user coverage, given the blacklisting we
> > did in glibc.
> >...
> 
> Skylake is not blacklisted anywhere, I assume?

Not by us, at least.  The processor model, firmware or microcode might
limit the availability of Intel TSX.

But it took quite a while for out-of-the-box Skylake BIOSes (i.e.
installed to the motherboard in the factory) to actually run Linux well
enough to finish a Debian install run (!).  Actually, it took a while
for it to do so even when the user updated the BIOS from the motherboard
vendor site before attempting to install Debian...

-- 
  Henrique de Moraes Holschuh 

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Thu, Nov 17, 2016, at 09:50, Adrian Bunk wrote:
> But we do already have > 1 year of widespread testing by users
> running unstable/testing on machines with TSX enabled.
> 
> So for unstable/stretch this does not seem to be a huge problem.
> 
> These are normal bugs that should be found and fixed if possible,
> just like passing a pointer in an int or many other kinds of bugs.
> 
> Or do I miss anything here?

I am not sure we have that much user coverage, given the blacklisting we
did in glibc.  Maybe a search for lock elision bug reports in relevant
Ubuntu releases would help... I think their glibc packages are close
enough to ours that they would have the same issues we do.

The current blacklist in Jessie's glibc is:
((model == 63 && stepping <= 2) || (model == 60 && stepping <= 3) ||
(model == 69 && stepping <= 1) || (model == 70 && stepping <= 1) ||
(model == 61 && stepping <= 4) || (model == 71 && stepping <= 1) ||
(model == 86 && stepping <= 2) ))

Which should be (ignoring ES/QS steppings, which were also blacklisted):

Haswell:
Signature: 0x306f2, main model: Haswell-E (Xeon E5v3, Core Extreme 4th
gen)
Signature: 0x306c3, main model: Haswell-DT (desktop Core 4th gen)
Signature: 0x40651, main model: Haswell low power (mobile Core  4th gen)
Signature: 0x40661, main model: Haswell "Crystal Well") (Core 4th gen
with eDRAM)

So, almost all of Haswell is blacklisted. The known exception is Xeon
E7v3 (signature 0x306f4), which was not blacklisted because apparently
either Intel TSX works well enough there, or it is never reported as
enabled in the first place.

Broadwell:
Signature: 0x306d4, main model: Broadwell (desktop and mobile Core 5th
gen)
Signature: 0x40671, main model: Broadwell "Brystal Well" (Core 5th gen
with eDRAM, also Xeon E3v4)
Signature: 0x50662, main model: Broadwell-DE (Xeon D-1500, stepping V1)
-- due to BDE42.

Note that newer steppings of Broadwell-DE are not blacklisted (0x50663:
stepping V2, 0x50664: stepping Y0 -- BDE85 fixed by up-to-date
microcode).   Also, Broadwell-EN/EP/EX (Core Extreme 5th gen,  Xeon E5v4
and E7v4) are not blacklisted, either.

-- 
  Henrique de Moraes Holschuh 

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Thu, Nov 17, 2016, at 09:11, Lucas Nussbaum wrote:
> On 17/11/16 at 08:31 -0200, Henrique de Moraes Holschuh wrote:
> > The deal with *current* Debian stable is that, if the breakage is too
> > widespread, we simply might not be able to do the right thing (fix the
> > real bugs).
> 
> Based on the number of bugs uncovered by my archive rebuild, I'm really
> not sure that this class of bugs is widespread, and requires to be
> special-cased. Relying on users to report problems, and then fix them
> is probably enough.

The rebuild was helpful, but it depends on the application/library
regression test suite to detect any application locking issues.  Not
every package has those, or runs those during build :-(

-- 
  Henrique de Moraes Holschuh 

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Sun, Nov 13, 2016, at 14:42, Lucas Nussbaum wrote:
> On 12/11/16 at 18:51 -0200, Henrique de Moraes Holschuh wrote:
> > Thanks for trying a build run with TSX enabled.
> > 
> > On Sat, 12 Nov 2016, Lucas Nussbaum wrote:
> > > I did an archive rebuild on Amazon EC2 using m4.16xlarge instances, that
> > > use a CPU with TSX enabled.
> > 
> > What microcode revision is that Xeon E5-2686 running?
> 
> microcode: CPU0 sig=0x406f1, pf=0x1, revision=0xb14

This is quite outdated, and it is in fact below the minimum recommended
revision for Linux use (as defined by "whatever Intel is distributing in
the latest Linux public microcode distribution" [1]).  I wouldn't trust
it for general production work, unless we're talking a distributed
application built upon resilient nodes and resilient inter-node result
cross-checking.  Kinda cloudy, I suppose :-)

Note that I don't think at all that it invalidates any results you got
about buildability under TSX.  It is just a reminder of yet another
reason to never trust the cloud too much.

It is also a reminder to ensure all of our (Debian) boxes are running
the latest relevant firmware update level and have the intel-microcode
package from stable non-free installed.

[1] Which is, as of 2016-11-04:
sig 0x000406f1, pf_mask 0xef, 2016-10-07, rev 0xb1f, size 25600

In a couple months[2], it will migrate to Debian stable, which currently
has:
sig 0x000406f1, pf_mask 0xef, 2016-06-06, rev 0xb1d, size 25600

[2] I enforce an one month quarantine in Debian testing before I even
submit a stable p-u request, and that one will typically sit in s-p-u
for a while (after it is approved) until the next stable point release
is out. Anyone that needs it earlier can get it from stable-backports. I
should upload the stable backport of intel-microcode 3.20161104-1 before
this weekend.

-- 
  Henrique de Moraes Holschuh 

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Wed, Nov 9, 2016, at 06:26, Lucas Nussbaum wrote:
> On 08/11/16 at 16:01 -0200, Henrique de Moraes Holschuh wrote:
> > I fear it might be bad, but
> > I would love to be pleasantly surprised that people did get libpthreads
> > locking right most of the time...
> 
> I wonder if it has been considered to "fix" glibc so that the misuses
> that are tolerated without TSX are also tolerated with TSX? Or is that
> impossible?

AFAIK, the hardware cannot be programed to tolerate this kind of
programming error.  And I don't think that's a bad thing. Locking bugs
are already subtle enough when the whole deal is fully visible to
software and depends only on trivial atomic operations on machine word
sizes (32-bit on ia32/amd64). Hidden by hardware transactional memory,
they would go from subtle and difficult to debug straight into utterly
nasty hellbug land if the hardware was too permissive about misuse.

One can handle the SIGSEGV and attempt to recover, I suppose -- which is
painful enough to get right, and that assumes such a thing is possible
at all in the first place: we are talking about a threaded application
here -- but that is so very slow, that it is simply not worth it as far
as I am concerned.  Not that I think it would be desirable to do so in
the first place: locking bugs are best fixed, not papered over.

This is an area where KISS is absolutely required, too.  Handling that
SIGSEGV to trigger a safe whole-application exit while saving user data
is one thing, attempting to resume execution from a signal raised while
inside an transactional state that has been aborted(!) is quite another.
 This is NOT the kind of thing I would ever trust current and future
processors to always get right.  It reeks of an errata minefield one
should never enter willing.

The deal with *current* Debian stable is that, if the breakage is too
widespread, we simply might not be able to do the right thing (fix the
real bugs).  IMHO, this is not a valid excuse to paper over the breakage
for unstable (or even the next stable, as far as I am concerned.  I'd
rather delay the release, although it is _not_ clear at this time that
such a thing would be needed).   It is not really about Intel TSX, it is
about broken locking that was *already* causing hard-to-debug issues in
many cases (I believe Ian said ghostscript was already showing hard to
debug hangs in this thread), and Intel TSX happened to expose.

-- 
  Henrique de Moraes Holschuh 

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

Lucas,

Thanks for trying a build run with TSX enabled.

On Sat, 12 Nov 2016, Lucas Nussbaum wrote:
> I did an archive rebuild on Amazon EC2 using m4.16xlarge instances, that
> use a CPU with TSX enabled.

What microcode revision is that Xeon E5-2686 running?

> I've filed bugs for the packages that failed during that rebuild, but
> don't fail on m4.large instances:
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=qa-ftbfs-2016;users=debian...@lists.debian.org

We still need that instrumented libc if one is to test applications,
though, as most packages have little in the way of automated regression
test suites.  And people need to test the packages (using the
applications) with such an instrumented libc installed (or running on a
box with TSX active).

-- 
  Henrique Holschuh

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Henrique de Moraes Holschuh]

On Fri, 11 Nov 2016, Christoph Biedl wrote:
> a proof of concept for all this (I can resist, though). The apt programs
> could obfuscate their request behaviour, the TLS layer could add random
> padding of data and time, but I doubt this would help much.

AFAIK, the TLS layer *does* bit-stuffing and random padding, but it
cannot do that to the point it would help the problem at hand, and still
be usable.

Bitstuffing TLS to the point it could (maybe) deal with the Debian
archive is the wrong solution for the problem anyway, so I won't expand
on this.

-- 
  Henrique Holschuh

Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)

[Henrique de Moraes Holschuh]

 /lib/x86_64-linux-gnu/libgpg-error.so.0
libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6


I assume I don't have to remind anyone of the security history of the
above library stack.  As far as I am concerned, enabling
apt-transport-https *is* a zero-day remote exploit waiting to happen, it
only depends on whether we will find out and patch the vulnerability it
first, or the attacker will exploit it first.

I'd prefer if we enhanced apt transports to run a lot more protected
(preferably under seccomp strict) before any such push for enabling
https transports in apt.  It would reduce the security impact a great
deal.

Mind you, at fist look it seems like apt transports will *run as root*
in Debian jessie.  HOWEVER I didn't do a deep check, just "ps aux" while
apt was running.  And I didn't check in unstable.  So, I (hopefully)
could be wrong about this.

Can you imagine trying to contain an exploit in the wild that will take
advantage of people trying to update their systems against said exploit
to spread even further?  Well, this is exactly what would happen.  We
should not enable apt-transport-https by default until we have _really_
hardened and contained the apt transports.

Now, hopefully I got all of that wrong and someone will set me straight.
 It would make me sleep better at night...

-- 
  Henrique de Moraes Holschuh 

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Tue, Nov 8, 2016, at 15:39, Ian Jackson wrote:
> Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive
> about pthread locks in stable ?"):
> > That said, I am not going to propose any changes to the glibc blacklist
> > at this time, unless new information about how well Intel TSX really
> > works in Broadwell becomes available.
> 
> So you think that the situation with jessie is OK ?

I better clarify what I meant, sorry about that.

Please take my comment above as in "I am not going to request that the
Broadwell blacklist in glibc be reduced at this time" just because we
got a microcode update that likely fixes any lingering defects in
Broadwell Intel TSX or properly disables it.  

I.e. my comment was about the correctness of the Intel TSX
implementation in up-to-date Broadwell, and not about the misuse of the
libpthreads API that causes programs with shoddy/broken locking to crash
with a SIGSEGV.

I don't think the situation in jessie is OK in the "things that misuse
libpthreads will crash" sense.  However, without some sort of test run,
we don't know how bad it really is, either.  I fear it might be bad, but
I would love to be pleasantly surprised that people did get libpthreads
locking right most of the time...

-- 
  Henrique de Moraes Holschuh 

Re: Build a sort-of-systemd-dependent package on kfreebsd

[Henrique de Moraes Holschuh]

On Tue, Nov 8, 2016, at 10:39, Alec Leamas wrote:
> I'm now trying to wrap my head around how to conditionalize a packet 
> such as lirc. I'm coming from Fedora/RPM and used to just spread some
> %ifarch in the spec file. Now, is something similar possible in debian?

It should be possible, yes.  I am not the best one to explain how, so I
will leave the actual answer to someone that could do it better.  

That said, I think you could get either better (or faster) help on
debian-ment...@lists.debian.org (which I added to Cc:). It is a list
specific to help new maintainers, and doubts about packaging corner
cases are routinely handled there.

-- 
  Henrique de Moraes Holschuh 

Re: call for participation - Debian contributors survey, 1st ed.

[Henrique de Moraes Holschuh]

On Mon, 07 Nov 2016, Stefano Zacchiroli wrote:
> On Mon, Nov 07, 2016 at 11:22:42PM +0100, Joerg Jaspert wrote:
> > No logging or name is needed, with the set of questions in this survey
> > one only needs a bit of knowledge of Debian and its people to identify a
> > high amount of the survey takers, I think. (I still took it)
> 
> This is becoming an FAQ, so let me address it here instead of just
> waiting for the blog post including its answer to be written.
> 
> Yep, you're absolutely right. And this is in fact why we included in the
> survey announcement a promise to distribute the results only in
> aggregate form, because cross-referencing with Debian info it would be
> easy to deanonymize people.
> 
> So the "thread model" here is not "untrusted/byzantine survey
> organizers" (if you don't trust the organizers you're probably screwed
> anyhow, as we could be lying about not logging IP address or HTTP
> referrers, after all).  The "threat model" is rather: "untrusted readers
> of published survey *results*", which we will aggregate to avoid
> deanonymization.

The threat model is leakage of the non-aggregated survey data, actually.
Which is not only dependent on the survey platform and its handling of
the survey data, but also on the security of said data *after* it leaves
the survey platform.

-- 
  Henrique Holschuh

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Mon, 07 Nov 2016, Lucas Nussbaum wrote:
> On 06/11/16 at 17:41 -0200, Henrique de Moraes Holschuh wrote:
> > On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > > It's worth noting that TSX is broken in 'Haswell' processors and is
> > > supposed to be disabled via a microcode update.  I don't know whether
> > > glibc avoids using it on these processors if the microcode update is
> > > not applied.  (Linux doesn't appear to hide the feature flags.)
> > 
> > It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
> > TSX use [in libpthreads] on all of Haswell and much of Broadwell.
> > 
> > But anything else *will* attempt to use it, people query cpuid directly
> > for these things.  You need a hypervisor that filters cpuid().
> 
> How can one know what glibc does on a given CPU? (preferably without
> access to the hardware)
> 
> I could try to run an archive rebuild on hardware where glibc leverages
> TSX to see what happens.

IMHO it would be better to instrument the locks in glibc with asserts,
instead.  You could use anything to test for pthread API violations,
then.

That said, if you are going to test Intel TSX for real, you need a
Desktop Skylake-based Core i5/i7 or Xeon E3v5 that reports "RTM" in
/proc/cpuinfo.  Some won't.

Not every Skylake model will have it enabled in the first place, and
apparently the firmware can (and some _do_) disable it, especially on
the mobile side.

Please ensure the Skylake firmware has microcode 0x9d/0x9e or later, or
install the latest version of the non-free intel-microcode package.  The
risk of unpredictable behaviour is quite real otherwise, and could mess
up the test results (and corrupt data).

Skylake errata are a nightmare. Note the AVX, AVX2, eDRAM (L4?), and TSX
ones, as well as the power-management ones:

http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e3-1200v5-spec-update.pdf
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/desktop-6th-gen-core-family-spec-update.pdf

Don't attempt to test TSX with perf or intel PT running.  perf is likely
to cause too many aborts, and Intel PT is an errata hell.

As for Broadwell, I don't know which processors would still have TSX
enabled in the first place when running the latest microcode, and we
blacklist most of them in glibc anyway (because almost all Broadwell-*
specification updates list it as either unavailable or unusable), so
they're not a very viable option to test this.

-- 
  Henrique Holschuh

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Sun, 06 Nov 2016, Adam Borowski wrote:
> On Sun, Nov 06, 2016 at 08:02:56PM +, Ian Jackson wrote:
> > Henrique de Moraes Holschuh writes ("Re: libc recently more aggressive 
> > about pthread locks in stable ?"):
> > > And what should we do about Debian stretch, then?
> > 
> > Perhaps we could add the assert you suggest, on non-lock-elision
> > hardware.  Whether to do that would depend on its performance impact.
> 
> Idea: what if we added the assert now, for a few months of testing on all
> hardware, then drop it during the freeze?

It doesn't even need to be added to production libc.  A debugger's
version of the package would be enough.

And we only need to instrument x86-64 (amd64), really.  It would be a
test corpus more than large enough, and typically fast enough to handle
whatever performance loss the extra check will cause.

Since this doesn't change lock type, it is far less intrusive than the
current options to root out such bugs.

-- 
  Henrique Holschuh

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Sun, 06 Nov 2016, Adrian Bunk wrote:
> On Sun, Nov 06, 2016 at 05:41:34PM -0200, Henrique de Moraes Holschuh wrote:
> > On Sun, 06 Nov 2016, Ben Hutchings wrote:
> > > It's worth noting that TSX is broken in 'Haswell' processors and is
> > > supposed to be disabled via a microcode update.  I don't know whether
> > > glibc avoids using it on these processors if the microcode update is
> > > not applied.  (Linux doesn't appear to hide the feature flags.)
> > 
> > It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
> > TSX use [in libpthreads] on all of Haswell and much of Broadwell.
> > 
> > But anything else *will* attempt to use it, people query cpuid directly
> > for these things.  You need a hypervisor that filters cpuid().
> 
> All users who are using intel-microcode from non-free instead of running 
> outdated microcode with known errata should be OK here?

Last time I checked, it looked like an yes for Skylake as far as Intel
TSX is concerned.

I don't know about the other processors, such as Broadwell-E.

-- 
  Henrique Holschuh

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Sun, 06 Nov 2016, Ben Hutchings wrote:
> It's worth noting that TSX is broken in 'Haswell' processors and is
> supposed to be disabled via a microcode update.  I don't know whether
> glibc avoids using it on these processors if the microcode update is
> not applied.  (Linux doesn't appear to hide the feature flags.)

It does avoid it.  For glibc libpthreads, Debian has blacklisted Intel
TSX use [in libpthreads] on all of Haswell and much of Broadwell.

But anything else *will* attempt to use it, people query cpuid directly
for these things.  You need a hypervisor that filters cpuid().

-- 
  Henrique Holschuh

Re: libc recently more aggressive about pthread locks in stable ?

[Henrique de Moraes Holschuh]

On Sat, 05 Nov 2016, Ian Jackson wrote:
> Looking at the code, I think that gs in jessie is plainly violating
> the rules about the use of pthread locks.  On my partner's machine,

Per logs from message #15 on bug #842796:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842796#15

SIGSEGV on __lll_unlock_elision is a signature (IME with very high
confidence) of an attempt to unlock an already unlocked lock while
running under hardware lock elision.


Well, unlocking an already unlocked lock is a pthreads API rule
violation, and it is going to crash the process on something that
implements hardware lock elision.

These would be Intel x86 processors with TSX enabled[1] for Debian
8/jessie.  For Debian 9/stretch and for unstable, I believe it also
includes IBM Power8, and s390x systems -- AFAIK they won't forgive an
attempt to unlock an unlocked lock any more than Intel TSX does.

[1] Broadwell-E, Skylake, and later processors, as well as Xeon *v5
processors.  I am not sure if we blacklisted any of the Xeon *v4
or not, and too tired to look their model numbers up right now.

Unfortunately, when hardware lock elision support was added to glibc
upstream, libpthreads was *not* changed to properly assert() this
forbidden condition on the non-hardware-elision codepaths.  Such an
assert() would have given us consistent behavior, thus flushing the bugs
out in the open... at the cost of a performance hit (I have no idea how
severe), and much screaming.

To be fair: it is likely nobody upstream had any idea of just how much
code got libpthreads usage wrong... and we certainly didn't know better
in Debian, either.  Well, now we're going to find out :-(

BTW, AFAIK libpthreads still doesn't have any such assert(), so there's
likely a lot of such buggy code in unstable still.  This is going to
cause trouble for Debian stretch, too.

> Has something changed in jessie's libc recently ?  I find it difficult
> to imagine that these bugs would have been missed earlier during the
> life of jessie.

The required hardware was not widely available at the time, the
knowledge of how hardware lock elision would really behave was sparse
outside of Intel and IBM -- so people either didn't know, or did not
grasp the importance of the fact that the hardware would be utterly
intolerant to something that the old code was too lenient about -- and
libpthreads was not instrumented to compensate for that.

I actually recommended that it would be safer to disable lock elision
for jessie[2]: the sharp corners nature of the code in glibc 2.19 scared
me, as well as just how messed up the implementation on Intel processors
were at the time.  Unfortunately, I didn't push for it at all: I didn't
know how correct I were at the time[3].

[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195#50

The hard truth is that nobody in Debian knew how deep those murky waters
were at the time[3], and I don't think glibc upstream developers did
either.  So, we limited ourselves in Debian to blacklisting the
processors where Intel (either for sure, or highly likely) screwed it up
beyond repair.

[3] A number of subtle Intel TSX errata were fixed by Skylake and
Broadwell microcode updates, and the latest ones are quite recent.
The until-then latent (or subtle) broken locking bugs in
applications/libs becoming high-hitter crashers as more users get
newer computers, etc.

Anyway, any library or application that hits this issue has broken
locking, plain and simple.

A package crashing from this issue very likely requires a stable update
to fix the locking (which won't always be a trivial fix, either), even
if we changed libpthreads to disable lock elision support and it stopped
the crashes -- even if it wouldn't crash anymore, the locking would
still be broken and therefore suspect of not being as effective as it
would have to be to ensure correct operation at all times.

> I will try to make a patch to fix ghostscript, or at least file a
> proper bug.  But, if there was a libc change, would it be possible to
> revert it or make some kind of workaround ?

If the problem is too widespread and too hard to fix on a large number
of packages, I suppose we could ask the glibc maintainers to consider
disabling hardware lock elision support in stable through a stable
update.

Such a change to glibc would likely requires some patches to ensure it
*really* disabled Intel TSX opcode/instruction insertion, but I think we
already ship all of them as part of the Intel TSX blacklist.  The result
would need real-world testing on an up-to-date Skylake box as well as
objdump inspection to ensure *no* TSX-related instructions leaked into
the binaries.

And what should we do about Debian stretch, then?

Some references:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824191
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195

-- 
  Henrique Holschuh

Re: Intended MBF: maintainer scripts not starting on #!

[Henrique de Moraes Holschuh]

On Sat, 05 Nov 2016, Santiago Vila wrote:
> On Sat, Nov 05, 2016 at 04:35:16PM -0200, Henrique de Moraes Holschuh wrote:
> > On Fri, 04 Nov 2016, Adrian Bunk wrote:
> > > If I would report hundreds of "dpkg-buildpackage -A" FTBFS bugs against 
> > > stable, would you consider that a valuable contribution to unhide 
> > > problems?
> > 
> > Packages in stable must build in stable.  If a package from stable FTBFS
> > in stable, then yes, you should report these bugs: they are relevant for
> > stable updates and security updates.
> 
> There must be hundreds of packages in jessie that build ok with
> "dpkg-buildpackage" but not with "dpkg-buildpackage -A". That's why
> being able to build with "dpkg-buildpackage -A" was made a release
> goal for stretch (but not retroactively for jessie).

Well, let's expand on that:

FTBFS in stable are [generally] relevant when they are going to get in
the way of security updates and stable updates, i.e. the stable package
FTBFS *in stable*, when being built the way it needs to be built in
stable to create a stable update or security update.

I am not sure dpkg-buildpackage -A is relevant for stable/security
updates, though.  stable updates and security updates [for jessie] are
done through a full upload plus a number of binary-arch uploads, so I'd
guess it isn't [for jessie].

I'd say it doesn't make sense to file a FTBFS bug against the stable
version of a package *when the unstable version has it already fixed*,
unless it is going to be actually relevant for stable and security
updates in stable.

-- 
  Henrique Holschuh

Re: Intended MBF: maintainer scripts not starting on #!

[Henrique de Moraes Holschuh]

On Fri, 04 Nov 2016, Adrian Bunk wrote:
> If I would report hundreds of "dpkg-buildpackage -A" FTBFS bugs against 
> stable, would you consider that a valuable contribution to unhide problems?

Packages in stable must build in stable.  If a package from stable FTBFS
in stable, then yes, you should report these bugs: they are relevant for
stable updates and security updates.

But when you do that, you should also check whether the issue was fixed
in unstable (i.e. the unstable package builds in unstable), and properly
record the issue as fixed by the version on unstable (or by the real
version that fixed it, if you care to/can track that down).

-- 
  Henrique Holschuh

Re: Static linking and fPIC (Was: Re: "PIE by default" transition is underway -- wiki needs updating)

[Henrique de Moraes Holschuh]

On Mon, 31 Oct 2016, Ian Campbell wrote:
> On Mon, 2016-10-31 at 10:27 +0100, Jérémy Lal wrote:
> > export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie
> > ?
> 
> Thanks, but that doesn't appear to help, I think the issue is to do
> with the changed default in gcc rather than the hardening settings

Which is actually a bug: hardening=-pie (now) needs to actually inject
flags to disable PIE, instead.

-- 
  Henrique Holschuh

Re: Planned NMU of w3-recs would use much archive disk space

[Henrique de Moraes Holschuh]

On Thu, 27 Oct 2016, Marco d'Itri wrote:
> On Oct 27, "Thaddeus H. Black"  wrote:
> > Unfortunately, without an NMU, this package would not be very
> > useful to stretch users.
> > 
> > I'd do what I could to trim the size, but this NMU will be big
> > no matter what I do.
> > 
> > Advice?  Objections?
> What is the purpose of this package?

Offline/local reference with all W3C standards in the "Recommended"
status.  Basically, the same locus as the packages with the IETF
standards and RFCs.

It is also (IMHO) far more useful than some of the monster packages we
already have in the archive, so I'd say go ahead even if it is 200GiB.
So I vote for "do it".

That said, Thaddeus, if you do go ahead with the upload please check if
you can minimize that size somehow, even just a 10% drop in size would
already be worth the work it took for something big like this.

For example, suppose it ships the recommendations in several rendered
formats (PDF, PS, HTML/XHTML) and master hypertext (XML DOCBOOK,
whatever).  It would be quite acceptable to drop everything but the
xhtml/html+css+images versions from the binary packages: people won't
install these to print, they will install them to read while working on
something (code, documents, etc) or researching, and browser-friendly
hypertext is MUCH better for search, cut-and-paste, reading, and
alternative renderings (voiced, etc) than PDF/PS/etc.

-- 
  Henrique Holschuh

Re: "PIE by default" transition is underway -- wiki needs updating

[Henrique de Moraes Holschuh]

On Wed, 26 Oct 2016, Adrian Bunk wrote:
> On Wed, Oct 26, 2016 at 05:37:06AM +0200, Adam Borowski wrote:
> > On Wed, Oct 26, 2016 at 12:37:18AM +0200, Andreas Cadhalpun wrote:
> > > The current policy says:
> > > "As to the static libraries, the common case is not to have relocatable 
> > > code"
> > > 
> > > As of gcc-6 version 6.2.0-7 this is factually wrong, because the compiler
> > > enables PIE by default, which means it produces relocatable code.
> > > This should definitely be updated to reflect reality.
> > 
> > It's not that simple.  The compiler enables PIE by default only:
> > * if you use "gcc" or "gcc-6".  gcc-5, clang, even gcc-snapshot still
> >   default to non-PIE.
> 
> The intention is that gcc-6 will be the only gcc version in stretch.

It needs to be able to compile the kernel correctly, first.  Which it
might not be able to right now (gcc 6.2.0), if one goes by code
generation issues reported in LKML (for other distros).  Hopefully it
will be fixed upstream by the time stretch is out, but it *is* a current
concern.

Also, the upstream kernel source needs to be fixed to deal with PIE
enabled by default (it is highly allergic to that).  This is already
ongoing AFAIK.

-- 
  Henrique Holschuh

Re: Keysafe dynamic UID

[Henrique de Moraes Holschuh]

On Sun, 23 Oct 2016, Guillem Jover wrote:
> Right now I'm actually considering going over the archive and sending
> patches to convert Debian-user and debian-user to _user…

Make it active only for new installs, and you will have bypassed the
most troublesome issue.  Just be *extremely* careful to actually do the
right thing on removal/purge when the package removes the user (some
don't, which is arguably MUCH safer), because you must *not* remove the
legacy user when both exists.

-- 
  Henrique Holschuh

Re: Bug#841113: ITP: extremetools -- tools for running processes under extreme uid and gid

[Henrique de Moraes Holschuh]

On Wed, Oct 19, 2016, at 06:56, Jan Mojzis wrote:
> >I read manpage on github, but did not understood, what exactly this
> > program provides.  Can it replace creation system users for dropping
> > privileges?
> 
> It's doesn't create users.
> It only drops privileges (extremesetuidgid) or sets $UID/$GID env.
> variables (extremeenvuidgid).
> 
> For example:
> extremesetuidgid -b 10 sleep 1
> 
> runs command 'sleep 1' under unprivileged uid/gid (computed getpid()
> +10) 
> e.g. for:
> pid=10 ... uid=gid=100010
> pid=11 ... uid=gid=100011
> pid=12 ... uid=gid=100011

I am just wondering why is it called "extreme"?

It looks more like a functionality related to "exclusive" guid/uid,
instead...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: Update GnuPG failed

[Henrique de Moraes Holschuh]

On Sat, 15 Oct 2016, Mechtilde wrote:
> There is gpg version 2.1.15-4.
> Unter Jessie all things are fine with gpg 1.4.18
> 
> Unter Stretch I have no access to my private key and the public keyring.
> I only see the keys which incomes with the mails after the update
> 
> What happens? The files of the secret key and the public keyring are
> identical with the backup and at the Jessie machine.
> 
> What is the best way to fix it?

Please direct this kind of question to the debian-users mailinglist...

-- 
  Henrique Holschuh

Re: Is the reason for closing the bug 837459 appropriate here?

[Henrique de Moraes Holschuh]

On Wed, 21 Sep 2016, Henrique de Moraes Holschuh wrote:
> for that backport, and refering to bug #836459...

Typo.  Make that bug #837459...

-- 
  Henrique Holschuh

Re: Is the reason for closing the bug 837459 appropriate here?

[Henrique de Moraes Holschuh]

On Wed, 21 Sep 2016, john.k...@vfemail.net wrote:
> Is the reason for closing the bug 837459 appropriate here? The bug is still
> here and no backported version.

I believe it was appropriately closed, yes.

#837459 is not a request for a backport.  Instead, it is a bug about
something that was already fixed in the versions of the package in
testing and unstable, so the maintainer closed the bug.

Proper version information was used when you opened bug, as well as when
it was closed, so the bug tracking system will list that bug as existing
in the version of the package in Debian stable, regardless of it being
closed or not.

The maintainer offered to do a backport *in the message that closed the
bug*, which is very nice of him (and not usual at all).  You answered 10
days ago that yes, you'd like that backport.

However, neither of you opened a new bug report about the backport
request.

I suggest you leave #837459 alone -- it was handled properly -- and if a
backport is not uploaded in some weeks (wait for at least a month, 10
days is certainly not enough), you could then either contact the
maintainer directly by email (and give him some time to answer -- he
might be on vacation or very busy), or file a new, *wishlist* bug asking
for that backport, and refering to bug #836459...

-- 
  Henrique Holschuh

Re: Network access during build

[Henrique de Moraes Holschuh]

On Thu, 08 Sep 2016, Russ Allbery wrote:
> gregor herrmann  writes:
> > IIRC (I didn't re-read the whole bug log now) the intention in
> > #770016 was indeed more than "not affect the build result" but
> > "explicitly forbid any attempt to access the network because leak".
> 
> > As a result policy 4.9. now says:
> 
> >  For packages in the main archive, no required targets may attempt
> >  network access.
> 
> > which in my understanding makes a DNS lookup for example.org in a
> > test which fails gracefully and has no relation whatsoever to the
> > resulting binary package a policy violation and thereby an RC bug.
> 
> > If this was not the original intention or if the community now comes
> > to the conclusion that this is maybe a bit over the top (as Russ' and
> > Vorlon's mails seem to imply, and I share their sentiments), I think
> > we need to change the wording in policy.
> 
> Yeah, I think we want a "must not fail when it doesn't have network
> access" (that's the legit RC bug, because it makes the build not work in

"must not change build behavior or build result depending on network
availability" is also needed somewhere, if it is not already in there.

-- 
  Henrique Holschuh

Re: Standards-Version field should be deprecated

[Henrique de Moraes Holschuh]

On Thu, 08 Sep 2016, Moritz Mühlenhoff wrote:
> We could reduce the policy checklist to issues not covered/coverable by
> Lintian tests (which should be a rather small subset of overall policy
> changes).

Please don't.  Feel free to annotate these, but don't remove them...

I would rather not depend on Lintian getting a test exactly right to
know there's something I should be looking at.

-- 
  Henrique Holschuh

Re: Thinking about a "jessie and a half" release

[Henrique de Moraes Holschuh]

On Tue, Jul 12, 2016, at 10:28, Jeffrey Walton wrote:

> [38229.510127] mce: [Hardware Error]: Machine check events logged
> 
> $ sudo mcelog
> mcelog: Family 6 Model 3d CPU: only decoding architectural errors

Update that bios/UEFI *and* install intel-microcode from
stable-proposed-updates or backports.

Looks like the rather easily triggered mce storm errata, so chances are
the newest microcode will stop that.  Of course, it could be a real
hardware defect as well.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: Thinking about a "jessie and a half" release

[Henrique de Moraes Holschuh]

On Sat, Jul 9, 2016, at 07:59, Ben Hutchings wrote:

> Non-free is not part of Debian so those components would need to be
> explicitly installed.
> 
> firmware-nonfree is up-to-date in backports (at least, it is in synch
> with testing and unstable).

And so are the microcode packages, which are absolutely required for
stable operation of at least Skylake and Broadwell right now (or your
data is toast due to TSX malfunction or one of the multiple undefined
behavior errata).  

One or two Skylake motherboards have good enough UEFI updates available,
but that's like 1% of them. This should get better in time, of course...
If people would update their firmware frequently in the first place.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Henrique de Moraes Holschuh]

On Fri, 12 Aug 2016, Ian Jackson wrote:
> Josh Triplett writes ("Re: use long keyid-format in gpg.conf (Re: Key 
> collisions in the wild"):
> > I'd suggest moving directly to full fingerprints; from elsewhere in this
> > thread, it sounds like the current version of gnupg has done so.
> 
> What should we do for users of jessie ?

IMO, backport the changes.

I personally won't really care whether the new format is enabled or disabled by
default, as long as a NEWS.Debian and a security announcement are worded
clearly enough to get the word out that it should be enabled everywhere
it won't cause breakages.

-- 
  Henrique Holschuh

Re: Please raise your opinion to package size and the given options to restrict it (Was: Bug#833388: ITP: metaphlan2 -- Metagenomic Phylogenetic Analysis)

[Henrique de Moraes Holschuh]

On Thu, 04 Aug 2016, Holger Levsen wrote:
> On Thu, Aug 04, 2016 at 09:30:19AM +0200, Andreas Tille wrote:
> [...]
> > >   2) When unpackaging the orig.tar.gz translating binary data to
> > >  text format and recompress using xz the tarball is "only" 265MB.
> > >  The transformation process takes about 30min on my Laptop - not
> > >  longer than any larger project might need to build but the
> > >  resulting binary package would have again close to 1GB.
> [...]
> > >  2b) Do the conversion of the format in postinst at the expense
> > >  of users time which is acceptable since the package usually
> > >  unpacks on high performance machines and not so many
> > >  installations which means bandwidth and disk space on Debian
> > >  mirrors should be saved here instead of users machine
> > > 
> > >  Source tarball 256MB + binary package ~250MB (estimated)
> 
> this seems the most reasonable option to me.

Agreed, although the option to download the dataset from upstream is
also a valid choice.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Henrique de Moraes Holschuh]

On Sat, 09 Jul 2016, german...@ya.ru wrote:
> >If you are very conservative on these matters, your two choices are ext4 and 
> >XFS.
> 
> I don't want XFS because it has weak journaling compared with "data=journal" 
> mode of ext3/4.

The data=journal mode of ext4 is less stable than the default
data=ordered mode.  It is not widely used, and it has a higher risk of
regressions because of that.

> I tried to use ext4 on Debian Stable due to metadata checksums, but
> then discovered that e2fsck doesn't support this feature. So currently
> I just decided to stick with ext3.

Do yourself a favor and just stick to ext4.

The ext3 kernel driver was put out of its misery due to bitrot, and you
will be using the ext4 driver to run any ext3 filesystem anyway...

> > Then, your case is pretty clear: stay away from brtfs.
> 
> How about using ZFS? 

It would be a choice were you using FreeBSD.  ZFS on Linux is *not*
anywhere close to the same level of stability as native ZFS on FreeBSD
(or ext4/XFS on Linux, for that matter).

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

[Henrique de Moraes Holschuh]

On Fri, 08 Jul 2016, german...@ya.ru wrote:
> I value stability of a FS over other considerations like shiny new
> features and performance. I know that Debian Stable includes only that

Then, your case is pretty clear: stay away from brtfs.  If you are very
conservative on these matters, your two choices are ext4 and XFS.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Gitlab and the BTS (was Re: Genesis of the git.d.o/gitlab.d.o confusion)

[Henrique de Moraes Holschuh]

On Fri, 10 Jun 2016, Jonathan Dowland wrote:
> I was wondering what the Gitlab proponent's thoughts are on how the Issue
> tracker functionality of Gitlab should be used in a Debian context,
> particularly in how it might intersect/interact/conflict with the BTS.

You can enable/disable it per project, might be a good idea to leave it
enabled for upstream projects, and leave it disabled for debian package
projects.

Also, you can use external "issue trackers" in gitlab, and these are
also per-project.  It has special support for Redmine and Jira (one for
the Debian BTS would have to be written).  It has very limited support
for an email workflow in its native issue tracker.

I didn't check how well the native gitlab issue tracker would play with
the Debian BTS upstream forwarding.  But it is way more limited/simpler
than the Debian BTS.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Bug#825821: ITP: neomutt -- NeoMutt is a place to gather all the patches against Mutt.

[Henrique de Moraes Holschuh]

On Tue, May 31, 2016, at 09:49, Antonio Radici wrote:
> Additionally I'm not sure why debian-devel@ was added to this bug.

All ITP bugs are CC'd to debian-devel.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: Bug#824884: netbase: should not recommend ifupdown

[Henrique de Moraes Holschuh]

On Tue, May 24, 2016, at 13:03, Ansgar Burchardt wrote:
> On Tue, 2016-05-24 at 11:43 -0300, Henrique de Moraes Holschuh wrote:
> > On Tue, May 24, 2016, at 10:01, Simon McVittie wrote:
> > > On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh
> > > wrote:
> > > > Whatever we do, we absolutely must bring up a fully configured
> > > > loopback
> > > > interface by default.
> > > Happily, our default init system already does that.
> > We need to ensure any non-default ones also do that before we drop
> > ifupdown from "recommends", because ifupdown + default
> > /etc/network/interfaces is the fallback that ensures the loopback
> > will be up.
> 
> We are not talking about removing "ifupdown" from the default
> installation which includes all "Priority: important" packages (which
> happens to include both netbase and ifupdown).
> 
> The only installations affected are debootstrap's "minbase" and
> "buildd" variants: these only install "Priority: required" packages and
> select extra packages (apt and, for buildd, build-essential).  These
> would no longer pull in "ifupdown" if "netbase" is installed.

As far as I am concerned, ensuring the "master namespace" loopback is
configured and up is actually required behavior and it should be
enforced by something stronger than "priority important" packages being
installed.  Systemd got this right.

So, yes, I do think it would be best were it done by something in the
initscripts package, since systemd is already doing it by itself as
well.

Also, it is "probably not ok" (as in I fully expect we will end up with
people filling severity critical bugs should we do otherwise) to allow
ifupdown (and likely netbase) to get uninstalled anywhere it was
automatically installed, unless we ensure something else will take up
their job.   This is not even related to configuring the loopback, but
rather to /etc/network/interfaces processing, as well as /etc/services.

People sometimes trigger firewall setup and other supplementary
network-related setup  using the loopback entry in
/etc/network/interfaces, because it is guaranteed to happen at the
exactly the right time during boot and fully serialized with other
interface bring-up.  And people do configure network services using
names from /etc/services instead of hard-coding port numbers (sometimes
by not specifying a port number in the first place, and the
service/daemon/application using the IANA-assigned service *name* in
that case to look up the port number). 

That said, I don't expect this to be a real problem right now, but it is
something to keep in mind.  Obviously, it is not going to be an issue
for new installs, but it could be for the next stable upgrade.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: Bug#824884: netbase: should not recommend ifupdown

[Henrique de Moraes Holschuh]

On Tue, May 24, 2016, at 10:01, Simon McVittie wrote:
> On Tue, 24 May 2016 at 09:08:11 -0300, Henrique de Moraes Holschuh wrote:
> > Whatever we do, we absolutely must bring up a fully configured loopback
> > interface by default.
> 
> Happily, our default init system already does that.

We need to ensure any non-default ones also do that before we drop
ifupdown from "recommends", because ifupdown + default
/etc/network/interfaces is the fallback that ensures the loopback will
be up.

Hopefully we already do that, but it doesn't look like it from a fast
look at a jessie workstation.

> systemd's authors see the lo device as being less like networking and
> more like part of the "API" of a Linux machine, so pid 1 sets it up

Which actually makes a lot of sense, as it is in fact a critical
networking component on any modern Unix userland.   Drop/bring down the
loopback, and the world breaks in surprising ways, be it in Linux, the
BSDs, or Solaris.

> using. That seems like a reasonable approach to me.

It is reasonable, yes.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: Bug#824884: netbase: should not recommend ifupdown

[Henrique de Moraes Holschuh]

On Mon, May 23, 2016, at 22:54, Simon Richter wrote:
> On 21.05.2016 21:06, Michael Biebl wrote:
> > Personally I don't see a compelling reason why netbase should pull in a
> > specific network configuration system.
> > So +1 for dropping the Recommends.
> 
> It should probably pull in at least one -- ideally listing a sensible
> default for Desktop installations as the first alternative.

Whatever we do, we absolutely must bring up a fully configured loopback
interface by default.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: Packaging of static libraries

[Henrique de Moraes Holschuh]

On Sun, 10 Apr 2016, Clint Adams wrote:
> On Mon, Apr 11, 2016 at 12:13:20AM +0800, Paul Wise wrote:
> > We should change policy and packaging tools such that static linking
> > are not enabled by default and only enabled when there is a good
> > reason to do so; when requested by users or when there is some other
> 
> No, we should not.

Agreed.  The correct fix is to:

1) make it clearn that static linking is to be used only when strongly
justified (e.g. system rescue tools like sash).

2) add dependency metadata to track this, so that a tool can schedule
binNMUs as required when a statically-linked dependency gets updated, and so
that it won't cause extra heartburn for the security team.

3) add a way to automatically generate the metadata for (2) during package
build, otherwise it is pointless to even try.

I have a hunch we even have some (maybe even all) of this already...

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: Opt out style recommends

[Henrique de Moraes Holschuh]

On Fri, 08 Apr 2016, Russ Allbery wrote:
> So, where this goes wrong is the upower -> libimobiledevice4 dependency.
> As you say, the dependency is correct (or at least correct-ish): we don't
> want to dlopen everything and try to push all those patches upstream.  But
> this is the weakest link of this whole chain, yet has the strongest
> dependency.
> 
> I think a more correct fix would (unfortunately) involve a new binary
> package field that we don't currently have: Depends-Shallow (for lack of a
> better term) that acts like Depends *except* disables Recommends
> processing for anything below the shallow dependencies in the tree.  So if
> everything you're installing only Depends-Shallow on libimobiledevice4,
> you don't get the recommendation; if anything straight depends on it, you
> do.

Make it "downgrades recommends to suggests" and it might even work well.

But since there exists recommends one is much better off never downgrading,
we might end up needing a recommends-strong field as well that would never
be downgraded, to avoid the need to upgrade such recommends to depends.

At least it would end there with two extra headers (or some other way to
annotate recommends dependency headers in these two ways), so it is still
something that looks like it could work.

But how much of a trouble would such changes cause for the dependency
solvers?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Re: support for merged /usr in Debian

[Henrique de Moraes Holschuh]

On Sun, Jan 3, 2016, at 19:59, Christian Seiler wrote:
> On 01/03/2016 10:53 PM, Henrique de Moraes Holschuh wrote:
> > On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:
> >> My question would be: would those people here who have separate /usr
> >> and aren't using initrd be willing to put up with something like that?
> > 
> > I don't know if they will, but the list of potential users for your hack
> > is a bit larger:
> > 
> > As far as I know, the Linux kernel cannot really support a
> > firmware-update/override "early initramfs" without a "boot" initramfs,
> > which is a really annoying limitation for anyone that doesn't want a
> > "boot" initramfs for whatever reason.
> 
> Oh, I didn't know that. I've always used initrds on my systems for the
> last - I don't know - 15 years or so.
> 
> Anyway, if I hear from enough people who'd actually use my piece of
> code, I'll make a real project out of it and package it for Debian.
> (Do you count yourself as one of those?)

No, but I've had to help a couple people that needed a microcode update
and couldn't make it work because they didn't use an initramfs.  Not all
of them were Debian users, though.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: support for merged /usr in Debian

[Henrique de Moraes Holschuh]

On Sun, Jan 3, 2016, at 18:35, Christian Seiler wrote:

> Well, just for the heck of it I wrote a braindead-simple initrd
> implementation in just 300 LOC:
> 
> https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae

Oho!  Cool!

> My question would be: would those people here who have separate /usr
> and aren't using initrd be willing to put up with something like that?

I don't know if they will, but the list of potential users for your hack
is a bit larger:

As far as I know, the Linux kernel cannot really support a
firmware-update/override "early initramfs" without a "boot" initramfs,
which is a really annoying limitation for anyone that doesn't want a
"boot" initramfs for whatever reason.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh 

Re: support for merged /usr in Debian

[Henrique de Moraes Holschuh]

On Sun, Jan 3, 2016, at 16:43, Marco d'Itri wrote:
> I just have not found yet how to determine if the system was booted 
> using an initramfs or not. Does anybody have any hint?

I don't think there is any source for that information that one can
really trust ATM, AFAIK.

We could add it in userspace, but this is the kind of thing much better
done in the kernel (and it is trivial to do it there, too). That way, it
would not get in the way of creative ideas like some of the stuff posted
elsewhere in this thread, such as that 6KiB binary initramfs "init" stub
to keep working.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique de Moraes Holschuh