DevHeads.net

Postings by Andrew Lutomirski

Retiring u2f-hidraw-policy soon!

u2f-hidraw-policy is obsoleted by an upstream systemd change. Thanks to
the systemd people for doing this!

I have asked systemd to obsolete u2f-hidraw-policy in all branches when
they apply the update:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1753381" title="https://bugzilla.redhat.com/show_bug.cgi?id=1753381">https://bugzilla.redhat.com/show_bug.cgi?id=1753381</a>

and I'll be retiring u2f-hidraw-policy in rawhide soon. I guess that
Fedora policy says that I should *not* retire it in stable branches, so
I'll leave it alone there unless someone tells me otherwise.

Enjoy your new u2f devices with wider Linux support!

How should the nvme-cli package generate its host "NQN"?

There's a request for the nvme-cli package to generate a unique name
to use when connecting to NVMe-over-fabrics targets:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1633814" title="https://bugzilla.redhat.com/show_bug.cgi?id=1633814">https://bugzilla.redhat.com/show_bug.cgi?id=1633814</a>

I'm wondering what the right approach is. For the various Atomic
variants, ISTM it's not very nice for the package to generate files in
/etc in a postinstall script.

DNF producing nonsense results (and a bogus F28 updates compose?)

I just got some very strange behavior from dnf:

$ sudo dnf upgrade --best --allowerasing
Last metadata expiration check: 0:04:26 ago on Sat 05 May 2018 09:13:56 PM PDT.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
===============================================================================$
Upgrading:
vim-common x86_64 2:8.0.1788-1.fc28 updates 6.4 M
Removing:
vim-enhanced x86_64 2:8.0.1763-1.fc28 @upda

Debugging random suspend?

My laptop occasionally randomly suspends itself. When this happens,
it seems to happen quite a few times in a row, several seconds apart.
The journal has this to say:

Jan 03 20:44:25 ... systemd-logind[1106]: Suspending...

So *why* is logind suspending? It's happened five or six times while
I've been typing this email, and it's getting old.

Also, there's a security bug here. The actual suspend sequence appears to be:

1. Screen blanks
2. Fedora splash screen appears
3.

Pondering security update time frames

It seems to me that Fedora has three severe distribution wide issues
relating to security updates:

1. Updates, even critical security updates, are very slow. Getting an
update out involves creating a build and an update (which is
reasonably fast for most packages), pushing the update to
updates-testing, getting karma, and pushing to updates. The latter
three can happen in parallel in the best case. The big problem as I
see it is that pushing updates is painfully slow.

Is bodhi's stable request policy confused?

The web UI would not let me push my update to stable despite having
plenty of karma
(<a href="https://bodhi.fedoraproject.org/updates/fish-2.3.0-2.fc24" title="https://bodhi.fedoraproject.org/updates/fish-2.3.0-2.fc24">https://bodhi.fedoraproject.org/updates/fish-2.3.0-2.fc24</a>).

provenpackager request: fix keepassx for f24

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1338054" title="https://bugzilla.redhat.com/show_bug.cgi?id=1338054">https://bugzilla.redhat.com/show_bug.cgi?id=1338054</a>

Pushing a reasonable version of keepassx for f24 is apparently an accepted
freeze exception, but it hasn't happened. It would be rather unfortunate
if f24 final was released before this was dealt with.

Since fixing this is as simple as creating a bodhi update, can a
provenpackager just do it, please?

--Andy

unannounced soname bump: libglpk

I believe this is the list of broken packages in rawhide.

$ sudo dnf --disablerepo=\* --enablerepo=rawhide repoquery --whatrequires
'libglpk.so.36()(64bit)'
Fedora rawhide - x86_64 277 kB/s | 45 MB
02:46
Last metadata expiration check performed 0:01:51 ago on Fri Feb 19 09:08:26
2016.
4ti2-0:1.6.3-7.fc24.x86_64
4ti2-libs-0:1.6.3-7.fc24.x86_64
R-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
cbmc-0:5.3-3.fc24.x86_64
coin-or-lemon-0:1.3.1-6.fc24.x86_64
coin-or-lemon-tools-0:1.3.1-6.fc24.x86_64
java-shogun-0:4.0.1-0.9.git20160125.0382808.fc24.x86_64
lua-shogun-0:4.0.

review swap: nvme-cli

I'll gladly trade a simple review for a simple review:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1298019" title="https://bugzilla.redhat.com/show_bug.cgi?id=1298019">https://bugzilla.redhat.com/show_bug.cgi?id=1298019</a>

It's the command line tool for poking at nvme disks.

RFC: switching from grubby to grub2-mkconfig

Since the old proposal to have the bootloader automatically enumerate
boot options never went anywhere, can we do the next best thing?

Specifically, these days grub2-mkconfig appears to produce output
that's functionally identical to what grubby generates. Can we switch
new-kernel-pkg to just regenerate the grub2 config using
grub2-mkconfig instead of using grubby?

Debian has worked like this forever, and IMO it's superior in pretty
much all respects.

Update pushing and bugzilla workflow

This has been bugging me for a while: what's the best practice, or
even a good practice, for pushing updates to more than one Fedora
version at a time?

Suppose I that foo-1.0-1 is current in fc22, fc23, and rawhide. I
want to update them all to foo-1.0-2.

Obviously step 1 is to build all three new versions. Rawhide
automatically picks up the new build at the next compose. All is
well.

But now I want to submit fc22 and fc23 updates. The only option I'm
aware of is to submit two separate updates in bodhi.

Removing vm86 support?

Hi-

I'm asking here because Fedora seems to one of few distros that
enables CONFIG_VM86 on 32-bit kernels.

Would anyone object if the upstream kernel (and hence Fedora) removed
vm86 support? This would break 16-bit real mode programs under
dosemu. It would have no effect on 16-bit protected mode programs
under dosemu (i.e. anything that works on a 64-bit kernel), on dosbox
(which you should be using instead of dosemu anyway) or on KVM (which
is also a much better option than dosemu).

--Andy

DNF feature request: usefully undo updates-testing transactions, or clarify instructions

I just messed up and did:

# dnf --enablerepo=updates-testing upgrade

and upgraded everything instead of just the thing I was trying to
upgrade.

Requiring all files in /usr to be world-readable?

I filed an FPC ticket: <a href="https://fedorahosted.org/fpc/ticket/467" title="https://fedorahosted.org/fpc/ticket/467">https://fedorahosted.org/fpc/ticket/467</a>

Thoughts?

U2F and a review swap?

Has Fedora considered supporting U2F for its infrastructure. IMO it's
*much* nicer than standard Yubikeys.

On a related note, I will gladly swap a review for libu2f-host:

<a href="https://bugzilla.redhat.com/show_bug.cgi?id=1155826" title="https://bugzilla.redhat.com/show_bug.cgi?id=1155826">https://bugzilla.redhat.com/show_bug.cgi?id=1155826</a>

--Andy

New package Koji / Bodhi oddities?

Hi-

I have a new package. I just got this error:

Package: virtme
NVR: virtme-0.0.1-1.fc22
User: pbrobinson
Status: failed
Tag Operation: tagged
Into Tag: f22

virtme-0.0.1-1.fc22 unsuccessfully tagged into f22 by pbrobinson
Operation failed with the error:
<class 'koji.TagError'>: build virtme-0.0.1-1.fc22 already tagged (f22)

The f20 update (<a href="https://admin.fedoraproject.org/updates/virtme-0.0.1-1.fc20" title="https://admin.fedoraproject.org/updates/virtme-0.0.1-1.fc20">https://admin.fedoraproject.org/updates/virtme-0.0.1-1.fc20</a>)
has been stuck in updates-pending for four days.

Are there known issues somewhere in the pipeline?

Thanks,
Andy

Mass bug: packages should not auto-enable systemd units

Hi everyone-

This is a notice in accordance with the mass bug filing procedure.

A number of packages install systemd units and enable them
automatically. They should not.

Mass bug proposal: packages that auto-enable systemd units

Hi all-

I propose a mass bug against packages that install services and enable
them without using the preset mechanism. Some of these can be
security issues if they get installed as dependencies.

As a related issue, it may pay to review the default presets. For
example, rpcbind is enabled.

rpcbind is enabled by default, and gnome-boxes requires it

I don't know whether this should be a gnome-boxes bug, an rpcbind bug,
or a FESCo ticket, or something else, so I'm asking here.

rpcbind enables itself by default. This page says that it has a
specific exception, so it's okay:

<a href="https://fedoraproject.org/wiki/Starting_services_by_default" title="https://fedoraproject.org/wiki/Starting_services_by_default">https://fedoraproject.org/wiki/Starting_services_by_default</a>

I assume that the exception comes from the idea that server systems
probably want it on if they've installed it.

Reinstalling the bootloader

Once upon a time (Fedora 15? -- I've lost track), it was possible to
reinstall the bootloader using grub-install.

Nowadays it's a clusterfsck. I've managed to screw up my bootloader. Is
there a way to reinstall it without reinstalling the world? Would it make
sense to split the whole bootloader thing out of Anaconda such that it
would be possible to re-run it? I can access my install just fine using
chroot.

FWIW, the same question applies to upgrading the bootloader. Somehow I'm
on Fedora 20 using grub 0.97.

--Andy

yum upgrade creates /var/run/nologin

This has happened twice now. I run 'yum upgrade' and, all of a
sudden, /var/run/nologin exists. It contains a message telling me
that my system is still booting. This is, of course, a lie -- the
system has been up for quite a while, *and I'm logged in with the
screen locked*.

This is rather impolite. /var/run/nologin isn't owned by any package,
so I have no clue where to file the bug.

--Andy

Audit overhead and default rules

On a default Fedora installation, every system call incurs a fair
amount of overhead due to syscall auditing. This happens despite the
fact that syscalls aren't actually audited, except as part of AVC
denials.

The overhead is something like 20-40ns per syscall, and the total time
to do a simple syscall with auditing completely disabled is about 70ns
on my laptop. So this is actually a large effect.

What would people think about changing the default audit rules to add
something like '-t task,never'?

GIT development branches for packagers?

I have some trivial cleanups I want to make to a package a maintain.
These cleanups are trivial enough that I don't think they're worth a
new build. Should I commit them to the master branch? If so, I can
imagine a couple of issues:

- A provenpackager could kick off a rebuild for whatever reason (e.g.
dependency soname bump). That will (I think) inadvertently include my
changes.
- I need to think about whether to add a changelog entry or not. If
not, those changes might be included silently.

Should /usr/bin/Xorg (still) be setuid-root?

/usr/bin/Xorg is, and has been, setuid-root just about forever. I'm
wondering whether there's any good reason for it to remain
setuid-root.

Some arguments for setuid-root:
- People who still use startx or similar scripts need it.
- It's vaguely useful for testing xorg.conf changes.

Some arguments for clearing the setuid-root bit:
- People who use display managers (i.e. almost everyone) doesn't need
it to be setuid-root.
- Xorg is a giant attack surface.

Re: [pkgdb] python-boto ownership changed

On Mon, Jan 6, 2014 at 1:53 PM, Garrett Holmstrom
< ... at fedoraproject dot org> wrote:

Re: [pkgdb] python-boto ownership changed

[Third try to send this email.

Re: Should a working fedup in Fedora N's stable repository be a release criterion for N+1?

On Wed, Dec 18, 2013 at 12:24 PM, Adam Williamson < ... at redhat dot com> wrote:

Re: Should a working fedup in Fedora N's stable repository be a release criterion for N+1?

On Wed, Dec 18, 2013 at 11:37 AM, Markus Mayer < ... at gmx dot de> wrote:

Re: Should a working fedup in Fedora N's stable repository be a release criterion for N+1?

OK, so I'll re-ask my original question. Fedora 20 was released with
a broken update path from F19. Should the release criteria be
amended? This particular issue would have been avoided if F19's fedup
were frozen along with F20 and if all of the destined-for-stable
versions were tested together as a release criterion.

--Andy

Re: Should a working fedup in Fedora N's stable repository be a release criterion for N+1?

On Tue, Dec 17, 2013 at 6:47 PM, Michael Catanzaro < ... at gnome dot org> wrote: