Re: do we need CONFIG_UPROBES=y in our kernels?

[Andrew Lutomirski]

> On Feb 12, 2024, at 10:18 AM, Marius Schwarz  wrote:
>
> Hi,
>
> I excuse myself if this has been already discussed, bastion ML server was 
> blacklisted (has been removed btw).
>
> Short summary(for details use the source link):
>
> In a german developer blog article was the topic raised, that with uprobes 
> enabled, userland apps can i.e. circumvent tls security(and other 
> protections),
> by telling the kernel to probe the function calls with the uprobes api. As 
> this enables i.e. the hosting system of a vm or container, to track activity 
> inside the container, trust is lost i.e. from customer to hoster. To be fair, 
> you need to be root on the host to do this, but as it "wasn't possible 
> before", and it is "now" ( out in a greater public ), it tends to create 
> trust issues, just for being there*.
>
> As this only works with uprobes enabled and has no use case besides a 
> developer debugging apps, the question is:

With my kernel developer hat on, this is ridiculous.  Of course the
host of a container or VM can see what’s going on inside the
container/VM, and no amount of changing Fedora’s kernel configuration
will make a difference. The host can use a hypervisor or run a
different kernel or use ptrace or use perf or use nsenter or look at
/proc or use kprobes or use bpfttrace or use *any* bpf program with
memory-reading permission [0].

 This proposed change would serve to annoy Fedora users and have no
other benefit.

[0] it’s surprisingly poorly advertised, but, while BPF itself is
nominally memory-safe, eBPF usually exposes a function that serves as
a fairly complete escape hatch for reading user and kernel memory.


>
> Do we need this for all others out there enabled by default?
>
> If noone can name an app/lib that needs this outside of the C* development 
> process, a change proposal would be wise. maybe adding a kernel boot argument 
> switch?
>
> Source: http://blog.fefe.de/?ts=9b3a23b2
>
> *) You may not have a clue, what security auditors tell you about "a 
> vulnerability & it's just there, but inexploitable". I had a case 2 weeks 
> ago, about a missing patch for the ssh-agent CVE vulnerability in fedora's 
> openssh. Trust me, it will create trouble the more the topic is discussed in 
> the pubic.
>
>
> Best regards,
> Marius Schwarz
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: CVE-2021-4034: why is pkexec still a thing?

[Andrew Lutomirski]

On Mon, Jan 31, 2022 at 5:24 PM Steve Grubb  wrote:
>
> Hello Mirek,
>
> This is the most constructive reply I've seen in this thread.
>
> On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote:
> > > But doesn't satisfy our security requirements. If the kernel dbus project
> > > had been successful, then Linux would have had a rock solid basis to
> > > allow impersonation which would satisfy the security requirements and
> > > allow the desktop actually go through a common criteria certification if
> > > any one ever  wanted to do that. But as it stands, anything created by
> > > IPC is missing the necessary security context.
> >
> > I mean, yes. I read that as not a reason to stick with set-uid, but as a
> > reason to make that a priority, and drive the investment and the cultural
> > change; otherwise Linux security is just going to keep falling behind. OTOH
> > with the consolehelper history and a lot of similar examples, I don’t know
> > how to do any of that (make it a priority, drive the investment, drive the
> > cultural change).
>
> Linux needs a first class impersonation mechanism. This would be where the
> kernel bestows upon a process, certain attributes from another process. Both
> sides should agree so that no toke kidnapping is possible or forcing
> credentials on an unsuspecting process. With something like this, we can
> start to solve the security problems caused by IPC instantiation. I was
> really hoping kernel dbus was successful way back when.
>

Windows has a first class impersonation mechanism, and it's really
quite complicated and far from rock solid.  I don't think Linux should
go that direction.

But I'm a bit baffled by the assertion that anything created by IPC is
missing the necessary security context.  The entire world of
distributed systems is missing this security context.  When I issue
REST request or a gRPC request or really any network request at all, I
have precisely whatever context I specifically authenticate with for
that call.  And, other than the fact that most systems use rather weak
authentication systems (mostly bearer tokens), this is *good* -- it
means that the credential being presented is, by construction,
intentional on the part of the presenter.  It also means that
incorrect inferences aren't drawn.  For example, in a world where an
entire security context comes along with a request, if process A asks
database server B to write a row *over a network*, and B asks the
filesystem (C) to do the write, we don't magically attribute more of
B's context than we should to the write.

I would love to see a nice security model for IPC in the Linux kernel,
but I haven't seen a credible proposal.  This problem is *hard*.

As for setuid, I'm strongly of the opinion that setuid was and remains
a mistake.  Executing a process should never add privileges.
Replacing sudo, etc well probably requires a mechanism by which a
process can allow a daemon to either create children of that process
or replace that process (in the exec sense).  The SELinux label to
apply to the newly created process should be the daemon's decision --
it's far from obvious that a sudo'd program should inherit sudo's
caller's label.

--Andy

>
> > > And access decisions do not go through the audit system.
> >
> > For polkit, that would be… a 20-line patch?
>
> Probably a little more. The auditing would need to be selective and by admin
> control. Meaning, the admin may decide that they want auditing of one
> application's permission grants and not the other.
>
> > Sure, the invoking user’s configuration can be trusted only to the extent a
> > D-Bus server provides it correctly to Polkit, making the D-Bus servers a
> > part of the trusted codebase. Still, that would be pretty valuable at least
> > until the first successful exploit.
>
> I was hoping with kernel dbus, polkit would have examined the connections
> itself and asked the kernel for veracity of the request. I really wished that
> was given another try and everyone agreed on why it was necessary so that it
> could be articulated well to the people that have to say yes/no to the patch.
>
> -Steve
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

Re: Dynamic preemption support in Linux 5.12 kernel

[Andrew Lutomirski]

On Mon, Apr 26, 2021 at 1:29 PM Justin Forbes  wrote:
>
> On Mon, Apr 26, 2021 at 11:25 AM Vitaly Zaitsev via devel
>  wrote:
> >
> > On 25.04.2021 20:39, Artem Tim wrote:
> > > Please provide full PREEMPT mode by default in 5.12 kernel for desktop 
> > > variants. With 5.12 it is possible for user to change it without efforts 
> > > if they need this.
> >
> > +1 for this. Significantly reduces X11 input lag in full-screen games.
> >
>
> From a kernel standpoint, I do not think turning on CONFIG_PREEMPT is
> desired. That sets the *default* to PREEMPT, and changes the current
> situation. I plan to keep CONFIG_PREEMPT_VOLUNTARY as the default.

I'm curious: why do you prefer voluntary as the default instead of full preempt?

> The
> code introduced is odd, in that you can choose other options (none,
> voluntary, full) based on that starting point, but it doesn't allow
> you to default to anything else and keep CONFIG_PREEMPT_DYNAMIC on to
> choose more preemption than the default.

I've pinged the right people.  I'll try to make this happen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Fedora TPM1.2 Support

[Andrew Lutomirski]

On Wed, Dec 2, 2020 at 12:08 PM Jerry Snitselaar 
wrote:

>
> We are looking to no longer support TPM1.2 in RHEL9. Than raised the
> question with regards to opencryptoki-tpmtok if it should be changed in
> Fedora as well, so I thought I'd see what everyone thinks about future
> TPM1.2 support in Fedora. I know at one point in the last year or so
> trousers almost dropped from Fedora due to being orphaned for quite a
> while. From what I could find the following packages have dependencies:
>
> ecryptfs-utils  - --disable-tspi
> openconnect - looks like it will only build support if trousers-devel is
>   there, and makes use of tpm2-tss as well.
> strongswan  - --enable-tss-tss2 instead of --enable-tss-trousers?
> tboot   - the trousers dependency was just in a policy tool that has
> now
>   been deprecated upstream.
> opencryptoki-tpmtok - --disable-tpmtok
>
> tpm-quote-tools, tpm-tools, and trousers are all tpm1.2 specific
> packages.
>
> Another thing is that in the kernel there currently is no way to build
> with just tpm1.2 or tpm2.0 support so the kernel support for tpm1.2
> would still be there.
>
> I don't think Fedora needs to drop the tpm1.2 support if people want to
> continue supporting it, but wanted to put the question out there and see
> how everyone felt.
>
>

How much support is needed?  I've written some TPM1.2 code that no one
uses, so I don't personally care, but I'm pretty sure there are quite a few
systems around that use TPM 1.2  For example, until I manually did the
magic incantation to switch my laptop from its TPM 1.2 default to TPM 2
mode, it had TPM 1.2.  It's not even particularly old.

I think we should at least keep TPM 1.2 kernel support, but basic user
support where it's not too inconvenient seems reasonable.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Tue, Sep 29, 2020 at 4:00 AM Lennart Poettering 
wrote:

> On Di, 29.09.20 03:49, John M. Harris Jr (joh...@splentity.com) wrote:
>
> > Search domains have absolutely nothing to do with routing. Search
> domains are
> > specifically used for resolving non-FQDN to FQDN. This isn't a reliable
> way to
> > see what domains are handled by a VPN, or by any DNS server.
> >
> > The Red Hat VPN is a good example of this, as not every internal
> subdomain is
> > in search domains. That's the case for many VPNs, corporate or personal.
>
> Please read what I wrote: we have nothing better. And no it's not a
> perfectly complete solution, I am aware of that. Configure the routes
> explicitly if you want, it's easy, and add the extra domains to the
> per-interface route and all will be jolly. If you don't, then things
> will still work, but mean that queries that aren't listed in any
> search domains will be sent to both the VPN and the main iface DNS,
> thus the RH VPN will work perfectly fine — only drawback is that
> those internal domains not listed as search domains might be seen on
> the internet. But what would expect here happens? If you don't tell us
> the routing we cannot do fully perfect routing to your wishes, you
> need to give us something.
>
> Search domains on VPNs are an indicator that these domains are handled
> by the VPN, that's why we use them also as routing domains. But this
> doesn't mean it's the *only* routing domains we use. We use the ones
> you configure, primarily. But since the concept didn't previously exist
> we make the best from what we have.
>

These heuristics seem fairly problematic, but this is solvable.  Fedora has
a considerable amount of influence on GNOME and NetworkManager.  How about
adjusting the UI to actually cover these cases? The idea that the VPN
configuration would go off into the weeds if a new checkbox showed up seems
silly — setting up a VPN is fundamentally a power user operation.

This could all be first class parts of VPN config. There could be a set of
options: use this VPN to look up all DNS domains or use this VPN to look up
the following domains. Each domain in the list could have an optional
indication that the user *also* wants it to be a “search domain” to get the
behavior that a query with no trailing dot will try that domain as a
suffix.  And the behavior of broadcasting queries in parallel to the
non-VPN network should be configurable as well.  As someone who has
configured corporate and personal VPNs, I would have made use of these
options, and my various VPNs would all be configured differently.

Right now we have a situation where the underlying system is quite
configurable, but (in networking and elsewhere) GNOME likes to hide
detailed configuration in gsettings or otherwise make it very hard to
discover.  For things like touchpad config, I respect GNOME’s goal of
keeping it simple even if I disagree. For networking, I think that the
genuinely simple cases (connect to WiFi, use that WiFI) should be
approachable to non-technical users, but setting up something like a VPN is
inherently complex, and trying to hide that complexity makes everything
harder.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Mon, Sep 28, 2020 at 11:19 AM PGNet Dev  wrote:

> On 9/28/20 11:03 AM, Lennart Poettering wrote:
> > I have the strong suspicion that the same people who are
> > able to deploy working DNSSEC client side and are educated enough in
> > DNSSEC to know what that even means are also capable of replacing that
> > one symlink in /etc.
>
> i'll start with:  i'm generally a huge use-systemd-*-whenever-possible
> bigot.  aka, NOT an anti-systemd'er.
>
> but, this^ comment, though likely _true_, causes concern for those of us
> out here, in the peanut gallery.
>
> on
>
> as Paul Wouters has repeatedly pointed out ... others' use cases are not
> mine.
>
> and statements such as "It's easy to do using resolvectl" make me ...
> antsy.
>
> forcing use of, or switching by (coming) default, to solutions that cause
> significant breakage to working systems, is bad news. whether or not that
> breakage can be 'easily' worked around.
>
> easy != zero effort / zero cost.
>
> my typical 'small-office install' includes local split-horizon bind9
> implementation, as well as instances of both NSD4/Unbound, multiple VPN
> links, and varied routing for IPv4 & IPv6 dns queries, as well as general &
> specific traffic.  internal services/capabilities include mail, DNSSEC and
> instances of secure DNS (DoT/DoH), geoIP, etc etc.
>
> 'large-office' installs are correspondingly _more_ 'convoluted'.
>
> that said, it all works.  well.
>
> (my) users see/use a static /etc/resolv.conf, with, generally, a single
> nameserver entry.
>
> recent experiments (on F32, admittedly -- *not* yet F33) with
> NetworkManager &/or systemd-resolved here were nightmarish; a seemingly
> endless array of 'gotchas' ...
>
> after trying, and failing, to chase down & completely resolve all the
> problems, the functional solution i landed on was
>
>  (1) disable NetworkManager everywhere (yes, causes some current pain with
> laptops)
>

I would have expected NetworkManager to handle this kind of setup just
fine.  What went wrong?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Mon, Sep 28, 2020 at 11:07 AM Lennart Poettering 
wrote:

> On Mo, 28.09.20 13:20, Chuck Anderson (c...@alum.wpi.edu) wrote:
>
> > On Mon, Sep 28, 2020 at 04:59:17PM +, Zbigniew Jędrzejewski-Szmek
> wrote:
> > > On Mon, Sep 28, 2020 at 06:36:02PM +0200, Florian Weimer wrote:
> > > > * Andrew Lutomirski:
> > > >
> > > > > Paul may well have been mixing different things here, but I don't
> > > > > think you answered the one that seems like the most severe problem:
> > > > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > > > supplied by the upstream server.  One might reasonably debate
> whether
> > > > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > > > but I think it should honor the DO bit in client requests and
> return
> > > > > DNSSEC data.
> > > >
> > > > FWIW, this is <https://bugzilla.redhat.com/show_bug.cgi?id=1879028>.
> > >
> > > In an ideal world, we would just implement this missing functionality.
> > > It's definitely on the TODO list, and there has been some preparatory
> > > work done, but so far nobody found the time. If this is judged
> necessary,
> > > we'll raise the priority of that work. Nevertheless, I don't think it
> is
> > > such high priority — the number of people using DNSSEC is not too
> large,
> > > and they are generally power-users who understand how to specify a
> different
> > > server. So while definitely annoying, I didn't consider this a
> deal-breaker.
> >
> > DNSSEC is not meant for power-users, and it doesn't require specifying
> > "a different server".
> >
> > I thought Fedora was supposed to be First?  How can it be if Fedora
> > chooses to use/configure software by default that is missing critical
> > DNSSEC functionality and breaks DNS standards?
>
> DNSSEC doesn't really work client-side IRL. The DNS servers typical
> clients talk to generally do not implement what you need, and if they
> do not correctly. This means if you have a great network admin who set
> everything up right it might work, but DNSSEC on a laptop that moves
> around and connects to a WLAN here, and another WLAN there and a third
> WLAN over there is just a nightmare.
>
> If the other big OSes would enable DNSSEC client-side by default
> things might change, but neither Windows nor MacOS or Android do.
>
>
The old unbound-resolveconf actually worked quite well when I played with
it.  The only problem I had was that I couldn't load google.com from one
particular network.  Upon a bit of investigation, I discovered that the ISP
was maliciously replacing the A records for google.com with its own servers
to inject JavaScript.  So unbound-resolveconf's behavior was arguably
correct.  A better solution might have been to pop up some kind of
notification like "your network is attempting to tamper with google.com.
You can use the tampered version of google.com at your own risk by
following these instructions, or you could try to access the real google.com
by doing this other thing".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Mon, Sep 28, 2020 at 10:05 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Mon, Sep 28, 2020 at 09:44:13AM -0700, Andrew Lutomirski wrote:
> > After reading https://github.com/systemd/systemd/issues/8967, I really
> > don't think that systemd-resolved's benefits outweigh its harms as a
> > default resolver for Fedora.  If someone wants to write a
> > libfriendlydnsresolver and encourage/patch programs to use it instead of
> > using glibc's resolver or reading resolv.conf, then that could be debated
> > on its merits.  But the actual contents of /etc/resolv.conf should follow
> > the relevant standards, and systemd-resolved does not.
> >
> > Perhaps systemd-resolved could change its mind and decide to comply with
> > all relevant standards.  But until then, it seems inappropriate to me for
> > it to be the default in Fedora.
>
> Pfff, now I'm confused. Here is a case where systemd-resolved implements
> the
> standard, and some people were unhappy because they were relying on sloppy
> implementations which don't follow the RFC. Nevertheless, we added an
> opt-in
> switch to make this work. (Since this feature mostly matters in "special"
> setups like k8s, where you need to do a lot of local setup anyway,
> requiring
> a one-line option seems to be reasonable).
>

I agree that the "tld." case is probably unusual, and I didn't personally
know that anyone had an actual website set up like this until today, but as
someone who has configured DNS zones, I did know that it was valid to
attach records to a TLD.  And, indeed, loading https://dk./ on Firefox on
Fedora 32 works!

I'm reminded of
https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver.  That
change, as I recall, didn't end up accepted because it ran into a bunch of
corner cases and (at least at the time) didn't solve them all adequately.
I don't recall its proponents ever arguing that the corner cases were
*wrong*, though.  In contrast, for some reason, the proponents of
systemd-resolved are telling us that the corner cases aren't bugs, are
arguing that the plainly written text in the standards are somehow not the
standards, and are kindly offering to add non-default options to make
systemd-resolved do what it should do by default.

Sorry, but it really seems that systemd-resolved is not ready for prime
time.

To be clear, I personally do not like the model of having each client
application manage its own communication with the network's resolver (i.e.
what happens today when /etc/resolve.conf mentions whatever nameserver was
provided by DHCP), but I think that a better solution needs to be very well
thought through and to honor the expectation that whatever is in
/etc/resolv.conf actually follows the standards.  Programs that use the
glibc name resolution APIs or that use UDP via their favorite library are
not human beings who can be retrained to do things better -- they are
programs that were written to various manpages, standards, etc, and when
one of them asks getaddrinfo(3) to resolve "dk.", they don't mean "do
whatever the systemd-resolved authors thought this should do"; they meant
"resolve dk. as per POSIX and the RFCs.  Similarly, if a program submits a
perfectly valid EDNS query asking for DNSSEC data (note: I mean DO -- I'm
not referring to the AD bit or to any sort of server-side validation),
then, if the network supports DNSSEC, the result should include the
requested data.

If Fedora 33 is going to violate these assumptions, along with whatever
else might be broken that various people on this thread have alluded to,
IMO it should have an extremely good reason to do so.  I haven't seen one
yet.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Mon, Sep 28, 2020 at 11:04 AM Lennart Poettering 
wrote:

> On Mo, 28.09.20 18:36, Florian Weimer (fwei...@redhat.com) wrote:
>
> > * Andrew Lutomirski:
> >
> > > Paul may well have been mixing different things here, but I don't
> > > think you answered the one that seems like the most severe problem:
> > > systemd-resolved removed perfectly valid DNSSEC records that were
> > > supplied by the upstream server.  One might reasonably debate whether
> > > Fedora's default DNS resolver configuration should validate DNSSEC,
> > > but I think it should honor the DO bit in client requests and return
> > > DNSSEC data.
> >
> > FWIW, this is <https://bugzilla.redhat.com/show_bug.cgi?id=1879028>.
>
> It's on the TODO list. But this creates probems of its
> own. Propagating DO stuff as is cannot work for LLMNR, mDNS,
> company-scope DNS and so on, i.e. anything that isn't the official
> Internet DNS.
>
> systemd-resolved is not a traditional DNS server after all. It is a
> client to classic DNS, MulticastDNS, LLMNR, local definitions from
> /etc/hosts, synthetic records such as _gateway, localhost and the
> local hostname and similar, and then exposes the combination to
> clients. It also is capable of (limited) merging of DNS zones from
> different sources (think: you have a VPN connection with some zones
> the official internet doesn't have). Only one of these backends has a
> concept of DNSSEC + DO: classic DNS talking to upstream Internet DNS
> servers. Thus exposing DO to clients is a bit weird, it suggests
> clients could validate whatever we return with DNSSEC, but that isn't
> doable, stuff that doesn't come from classic Internet DNS cannot
> possibly be DNSSEC validated. So we'd have to have a weird split: for
> some domains we could propagate DO stuff, but for others we simply
> have to block out, because the requests simply doesn't make sense for
> it. What's worse, resolved would start having a split personality: for
> DO replies we'd propagate the 1:1 upstream responses, while for
> everything else we'd return our own stuff, from our own synthesis,
> sourcing and and son. A local DNS client talking to resolved would see
> a feature set that would be very different depending if you ask with
> or without DO, because if you ask with DO you effectively just talk to
> one of the upstream servers, while without you will speak to
> systemd-resolved. I can tell you from implementing much of
> systemd-resolved: dealing with a server that in some conditions acts
> like X and in other conditions like Y is super annoying. Many many
> home routers act like that: they synthesize records for the admin UI,
> which work very differently protocol-wise then talking to proper
> public Internet.
>

Indeed, the problem you're trying to solve is hard.


>
> systemd-resolved is not supposed to be a real DNS *server*. It's
> supposed to be a good, combined client for the popular name resolution
> protocols, and the fact that we also listen on a port 53 is mostly to
> provide compat with local app code that doesn't go through glibc NSS
> for its name resolution needs. If you expect a full blown DNS server
> on port 53 then it's not what systemd-resolved is or strives to be.
>

Then perhaps you should have a libsystemdresolvedclient and start
convincing programs that want this behavior to use it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Mon, Sep 28, 2020 at 9:27 AM Andrew Lutomirski  wrote:

> On Mon, Sep 28, 2020 at 4:48 AM Zbigniew Jędrzejewski-Szmek <
> zbys...@in.waw.pl> wrote:
>
>> On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
>> >
>> > >Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
>> >
>>
>> > paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
>> >
>> > ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec vpn.nohats.ca @
>> 127.0.0.53
>> > ;; global options: +cmd
>> > ;; Got answer:
>> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669
>> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>> >
>> > ;; OPT PSEUDOSECTION:
>> > ; EDNS: version: 0, flags: do; udp: 65494
>> > ; OPT=5: 05 07 08 0a 0d 0e 0f ("...")
>> > ; OPT=6: 01 02 04 ("...")
>> > ; OPT=7: 01 (".")
>> > ;; QUESTION SECTION:
>> > ;vpn.nohats.ca.   IN  A
>> >
>> > ;; ANSWER SECTION:
>> > vpn.nohats.ca.10  IN  A   193.110.157.148
>> >
>> > ;; Query time: 143 msec
>> > ;; SERVER: 127.0.0.53#53(127.0.0.53)
>> > ;; WHEN: Mon Sep 28 00:18:32 EDT 2020
>> > ;; MSG SIZE  rcvd: 81
>> >
>> > libreswan will see this result as an attack, and fail to resolve DNS
>> names
>> > in its configuration. My postfix daemon will hold on to mail because
>> > it cannot get a DNSSEC proof of denial of existence of TLSA records if
>> > all DNSSEC records are filtered - even for domains that don't use DNSSEC
>> > because the denial of existence of DNSSEC for a specific domain requires
>> > the return of DNSSEC records that systemd now does not return.
>> >
>> > I am sorry that I did not follow the fedora list carefully enough to
>> > notice this feature when it was proposed.
>> >
>> > This change is harmful to network security, impacts existing
>> installations
>> > depending on DNSSEC security, and leaks private queries for VPN/internal
>> > domains to the open internet, and prefers faster non-dnssec answers
>> > over dnssec validated answers.  It fails various types of queries,
>> > misimplements part of the DNS protocol. Not only according to me, but
>> > to 20years+ developers of the bind software as well.
>>
>> You're mixing a few different things here. We decided to not enable
>> DNSSEC in resolved with this change, at least initially. For most
>> users, DNSSEC is problematic because various intermediary DNS servers
>> found in hotspots and routers don't support DNSSEC properly, leading
>> to hard-to-debug validation failures. DNSSEC support in resolved can
>> be enabled through resolved.conf. This may be a reasonable thing to do in
>> an environment where the configured dns servers are known to support
>> dnssec
>> properly.
>>
>
> Paul may well have been mixing different things here, but I don't think
> you answered the one that seems like the most severe problem:
> systemd-resolved removed perfectly valid DNSSEC records that were supplied
> by the upstream server.  One might reasonably debate whether Fedora's
> default DNS resolver configuration should validate DNSSEC, but I think it
> should honor the DO bit in client requests and return DNSSEC data.
>
> Could the F33 default be changed to at least forward DNSSEC data to
> clients that ask for it?
>
> (My personal view is that either this should happen or that
> systemd-resolved-as-default should be reverted for F33, but I'm not on
> FESCo.)
>

I should add:

After reading https://github.com/systemd/systemd/issues/8967, I really
don't think that systemd-resolved's benefits outweigh its harms as a
default resolver for Fedora.  If someone wants to write a
libfriendlydnsresolver and encourage/patch programs to use it instead of
using glibc's resolver or reading resolv.conf, then that could be debated
on its merits.  But the actual contents of /etc/resolv.conf should follow
the relevant standards, and systemd-resolved does not.

Perhaps systemd-resolved could change its mind and decide to comply with
all relevant standards.  But until then, it seems inappropriate to me for
it to be the default in Fedora.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: This is bad, was Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Mon, Sep 28, 2020 at 4:48 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Mon, Sep 28, 2020 at 12:44:13AM -0400, Paul Wouters wrote:
> >
> > >Subject: Re: Fedora 33 System-Wide Change proposal: systemd-resolved
> >
>
> > paul@thinkpad:~$ dig +dnssec vpn.nohats.ca @127.0.0.53
> >
> > ; <<>> DiG 9.11.22-RedHat-9.11.22-1.fc33 <<>> +dnssec vpn.nohats.ca @
> 127.0.0.53
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51669
> > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags: do; udp: 65494
> > ; OPT=5: 05 07 08 0a 0d 0e 0f ("...")
> > ; OPT=6: 01 02 04 ("...")
> > ; OPT=7: 01 (".")
> > ;; QUESTION SECTION:
> > ;vpn.nohats.ca.   IN  A
> >
> > ;; ANSWER SECTION:
> > vpn.nohats.ca.10  IN  A   193.110.157.148
> >
> > ;; Query time: 143 msec
> > ;; SERVER: 127.0.0.53#53(127.0.0.53)
> > ;; WHEN: Mon Sep 28 00:18:32 EDT 2020
> > ;; MSG SIZE  rcvd: 81
> >
> > libreswan will see this result as an attack, and fail to resolve DNS
> names
> > in its configuration. My postfix daemon will hold on to mail because
> > it cannot get a DNSSEC proof of denial of existence of TLSA records if
> > all DNSSEC records are filtered - even for domains that don't use DNSSEC
> > because the denial of existence of DNSSEC for a specific domain requires
> > the return of DNSSEC records that systemd now does not return.
> >
> > I am sorry that I did not follow the fedora list carefully enough to
> > notice this feature when it was proposed.
> >
> > This change is harmful to network security, impacts existing
> installations
> > depending on DNSSEC security, and leaks private queries for VPN/internal
> > domains to the open internet, and prefers faster non-dnssec answers
> > over dnssec validated answers.  It fails various types of queries,
> > misimplements part of the DNS protocol. Not only according to me, but
> > to 20years+ developers of the bind software as well.
>
> You're mixing a few different things here. We decided to not enable
> DNSSEC in resolved with this change, at least initially. For most
> users, DNSSEC is problematic because various intermediary DNS servers
> found in hotspots and routers don't support DNSSEC properly, leading
> to hard-to-debug validation failures. DNSSEC support in resolved can
> be enabled through resolved.conf. This may be a reasonable thing to do in
> an environment where the configured dns servers are known to support dnssec
> properly.
>

Paul may well have been mixing different things here, but I don't think you
answered the one that seems like the most severe problem: systemd-resolved
removed perfectly valid DNSSEC records that were supplied by the upstream
server.  One might reasonably debate whether Fedora's default DNS resolver
configuration should validate DNSSEC, but I think it should honor the DO
bit in client requests and return DNSSEC data.

Could the F33 default be changed to at least forward DNSSEC data to clients
that ask for it?

(My personal view is that either this should happen or that
systemd-resolved-as-default should be reverted for F33, but I'm not on
FESCo.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 33 System-Wide Change proposal: systemd-resolved

[Andrew Lutomirski]

On Fri, Apr 17, 2020 at 8:34 AM Chris Adams  wrote:

> Once upon a time, Lennart Poettering  said:
> > The DNS servers in edge routers are awful at supporting
> > either. i.e. the DNS servers you usually get informed about in DHCP
> > leases are typically too crap at supporting either kind of DNSSEC (and
> > that for a reason actually, these devices generally define their own
> > private, local DNS names (e.g. "fritz.box"), which couldn't possibly
> > be validated with DNSSEC, because they are made up and local.)
>
> That might be true if you are just considering residential users with
> cheap gateways as your only use case (but even then, most of those run
> dnsmasq, which has gotten a lot better).  However, there are lots of
> other use cases.
>
> > We
> > intend to implement the "AD" stuff however correctly for this, but
> > this isn't tested much since pretty much noone except for a few DNS
> > devs actually set this, hence there might be issues, which might be
> > what Florian found.
>
> Advertising yourself as a "nameserver" in /etc/resolv.conf means you get
> to handle all the requests, including the ones you didn't think about or
> want to just dismiss as only of interest "a few DNS devs".  That's the
> only standard way for software to find DNS servers to use for any
> purpose.  Returning errors to clients for things you don't care about is
> basically useless, because they have no other way to get that
> information when actual DNS servers aren't in /etc/resolv.conf.
>
> If systemd-resolved is not going to implement a standards-compliant DNS
> server (and not just "we return errors to things we don't care about",
> but actual current DNS standards), then it does not belong in
> /etc/resolv.conf.  Listening on the system bus as an alternative, to
> implment gethostbyname/getaddrinfo/etc., is fine, but don't pretend to
> be an actual DNS server and go in /etc/resolv.conf.
>

I tend to agree.  Right now, a client-side resolving validator works on
Fedora.  This change proposal breaks that.  Could resolved be extended to
pass DNSSEC data through correctly so that client side validation will
continue to work?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Update: AAA replacement login Initiative

[Andrew Lutomirski]

On Sat, Jan 25, 2020 at 1:48 AM Adam Williamson 
wrote:

> On Fri, 2020-01-17 at 13:29 -0700, Jerry James wrote:
> > On Fri, Jan 17, 2020 at 12:52 PM Andrew Lutomirski  wrote:
> > > And I have a user story: Andy wants to use a password manager to store
> > > his password for an account in the Online Accounts list. When it’s
> > > time to log in, Andy clicks the account and a system modal dialog
> > > appears asking for a password. Andy would like to click the account in
> > > the password manager and copy the password, but he can’t, because the
> > > dialog is system modal.  So instead, Andy grumbles, dismisses the
> > > dialog, copies the password, and then tries to get the dialog to
> > > reappear before the copied password is auto-cleared from the
> > > clipboard.  Andy also wonders why the system modal dialog is not
> > > visually consistent with the Online Accounts application at all.
> >
> > It isn't just you.  I HATE that modal dialog.  I actively dislike
> > modal dialogs in general, but that particular one has tripped me up so
> > many times
>
> So do I, but it has nothing at all to do with this. That's a GNOME UI
> choice. The authentication system GNOME is talking to has no control
> over it at all.
>
> There has been a GNOME bug open on it approximately forever, btw:
>
> https://bugzilla.gnome.org/show_bug.cgi?id=688434
>

And this, which I just commented on:

https://gitlab.gnome.org/GNOME/gnome-shell/issues/1410

I would argue that having gnome-online-accounts blame gnome-shell for this
is actually a bit inappropriate.  The behavior of whatever GTK or GNOME API
is being used by gnome-online-accounts is simply so poor that
gnome-online-accounts should stop using it.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Update: AAA replacement login Initiative

[Andrew Lutomirski]

On Fri, Jan 17, 2020 at 1:22 PM Kevin Fenzi  wrote:

> On Fri, Jan 17, 2020 at 11:51:35AM -0800, Andrew Lutomirski wrote:
> > > On Jan 16, 2020, at 3:48 AM, Sarah Finn  wrote:
> > >
> > > 
> > > Hi all,
> > >
> > > I hope you are all well.
> > >
> > > I would like to invite you to contribute to our new initiative: AAA
> replacement login.
> > >
> >
> > I’ll offer a couple of suggestions:
> >
>
> Can you please offer these to gnome developers?
>
> https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues
>

https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/100

https://gitlab.gnome.org/GNOME/gnome-online-accounts/issues/101
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Update: AAA replacement login Initiative

[Andrew Lutomirski]

> On Jan 16, 2020, at 3:48 AM, Sarah Finn  wrote:
>
> 
> Hi all,
>
> I hope you are all well.
>
> I would like to invite you to contribute to our new initiative: AAA 
> replacement login.
>

I’ll offer a couple of suggestions:

Right now, I enter my Fedora developer password into GNOME Online
Accounts. It regularly stops working with a worthless message and I
have to re-enter my password. Maybe it could remember enough of a
secret to re-authenticate by itself for a while.

And I have a user story: Andy wants to use a password manager to store
his password for an account in the Online Accounts list. When it’s
time to log in, Andy clicks the account and a system modal dialog
appears asking for a password. Andy would like to click the account in
the password manager and copy the password, but he can’t, because the
dialog is system modal.  So instead, Andy grumbles, dismisses the
dialog, copies the password, and then tries to get the dialog to
reappear before the copied password is auto-cleared from the
clipboard.  Andy also wonders why the system modal dialog is not
visually consistent with the Online Accounts application at all.

Yes, this is a bit snarky, but there’s a reason that Microsoft
separated system modal dialog boxes decades ago.  The fact that  GNOME
supports this grotesque anti-pattern and NetworkManager uses it does
not justify using it in anything else.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: systemd 244-rc1

[Andrew Lutomirski]

On Fri, Nov 22, 2019 at 8:19 AM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> Hi,
>
> a new systemd has been sent to rawhide. I don't expect any major
> trouble, but please report any issues.
>
> Quoting %changelog:
>   Biggest items: cgroups v2 cpuset controller, fido_id builtin in udev,
>

fido_id is exciting -- it means that U2F devices will work without needing
to install u2f-hidraw-policy.

I retired u2f-hidraw-policy in Rawhide.  Long live fido_id.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Retiring u2f-hidraw-policy soon!

[Andrew Lutomirski]

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:

https://bugzilla.redhat.com/show_bug.cgi?id=1753381

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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Andrew Lutomirski]

On Mon, Aug 5, 2019 at 8:22 AM Andrew Lutomirski  wrote:
>
> On Sun, Aug 4, 2019 at 6:16 AM Sam Varshavchik  wrote:
> >
> > Georg Sauthoff writes:
> >
> > > > I ended up tweaking my code to avoid the assertions, rather than 
> > > > disabling
> > > > them. For this particular situation, my original change was to try
> > > >
> > > > std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});
> > > >
> > > > But that still tripped the assertion when the foo vector was empty, so I
> > > had
> > > > wrap this inside an if().
> > >
> > > But why don't you use the idiomatic
> > >
> > > copy(foo.begin(), foo.end(), back_inserter(bar));
> > >
> > > ?
> > >
> > > No need to wrap it into an extra if statement.
> >
> > I'm well aware of the alternatives. That's not the point.
> >
> > The point is that there's nothing wrong with this specific form of existing
> > code that now throws exceptions when the hardened build gets turned on.
> > There is no buffer overruns, and nothing to exploit.
> >
> > IIRC, the hardened build did find one real bug in the upstream package that
> > was the original subject matter here, but all of the rest were these kinds
> > of false positives. Now you have a situation when the existing code is known
> > to be working, but needs changing in order to use a hardened build. There's
> > some level of risk of regression in any change, and that gets weighed
> > against the benefits of having a hardened build.
> >
> > The above was just a basic example of this. It is not true that exceptions
> > from hardened code are always evidence of potentially exploitable problem.
> > Sometimes/most of the time, but sometimes they are false positives.
> >
> >
>
> I filed an upstream bug:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91357
>
> Depending on the resolution of that bug, I suggest that Fedora
> consider dropping _GLIBCXX_ASSERTIONS from the default hardened build
> options.  IMO Fedora's default RPM build options should not cause
> crashes on valid, if less-than-stylistically-great, code.  I don't
> think that package maintainers should need to update package source to
> use C++ in a more polite way.

And the bug has spoken.  v[v.size()] is undefined behavior.  Don't do it!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Andrew Lutomirski]

On Sun, Aug 4, 2019 at 6:16 AM Sam Varshavchik  wrote:
>
> Georg Sauthoff writes:
>
> > > I ended up tweaking my code to avoid the assertions, rather than disabling
> > > them. For this particular situation, my original change was to try
> > >
> > > std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});
> > >
> > > But that still tripped the assertion when the foo vector was empty, so I
> > had
> > > wrap this inside an if().
> >
> > But why don't you use the idiomatic
> >
> > copy(foo.begin(), foo.end(), back_inserter(bar));
> >
> > ?
> >
> > No need to wrap it into an extra if statement.
>
> I'm well aware of the alternatives. That's not the point.
>
> The point is that there's nothing wrong with this specific form of existing
> code that now throws exceptions when the hardened build gets turned on.
> There is no buffer overruns, and nothing to exploit.
>
> IIRC, the hardened build did find one real bug in the upstream package that
> was the original subject matter here, but all of the rest were these kinds
> of false positives. Now you have a situation when the existing code is known
> to be working, but needs changing in order to use a hardened build. There's
> some level of risk of regression in any change, and that gets weighed
> against the benefits of having a hardened build.
>
> The above was just a basic example of this. It is not true that exceptions
> from hardened code are always evidence of potentially exploitable problem.
> Sometimes/most of the time, but sometimes they are false positives.
>
>

I filed an upstream bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91357

Depending on the resolution of that bug, I suggest that Fedora
consider dropping _GLIBCXX_ASSERTIONS from the default hardened build
options.  IMO Fedora's default RPM build options should not cause
crashes on valid, if less-than-stylistically-great, code.  I don't
think that package maintainers should need to update package source to
use C++ in a more polite way.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Andrew Lutomirski]

On Sat, Aug 3, 2019 at 4:30 PM Sam Varshavchik  wrote:
>
> Tom Hughes writes:
>
> > But I think upstream is giving very bad advice...
> >
> > That define does not "add extra crashes" in the way that they
> > seem to think - well I mean it does literally but those crashes
> > are reports of program errors on their part.
> >
> > Specifically in this case they appear to be accessing a
> > std::vector at an index beyond the end, so they are accessing
> > memory that may not be allocated at all, and if it is does
> > not belong to the vector in question. So the program is quite
> > likely to crash there one day anyway, the extra assertion just
> > makes sure it always does.
>
> I believe that the following construct trips this assertion:
>
> # std::vector foo;
> #
> # std::vector bar;
> #
> # // Populate foo with something.
> #
> # std::copy([0], [foo.size()], std::back_insert_iterator{bar});
>
> There's nothing wrong with this. There is no out of bounds access.

You just formed a reference past the end of an array.  I doubt that is
valid according to the standard.  It certainly fails the smell test.

I *think* the standard defines [foo.size] as being equivalent to
&*(foo.begin() + foo.size()), which certainly appears to be invalid.
On a cursory search of the standard, I couldn't find where it says
what operator* on this type of iterator does at all, let alone whether
it's valid for one-past-the-end iterators, but I'm pretty sure that
your code is, indeed, wrong.

> I do not
> believe that this is undefined behavior. The defined semantics of
> std::vector, and its operator[], are well defined here.
>
> I ran into these new assertions with my own code as well, after updating to
> F28 (where they were enabled by default the first time, IIRC, not sure why
> this shows up only now, for that package).
>
> I ended up tweaking my code to avoid the assertions, rather than disabling
> them. For this particular situation, my original change was to try
>
> std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});
>

What you want is foo.begin() and foo.end() or, if you really want to
play with pointers, foo.data().
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Andrew Lutomirski]

On Mon, Jul 22, 2019 at 11:52 AM Ben Cotton  wrote:

> https://fedoraproject.org/wiki/Changes/x86-64_micro-architecture_update
>
> == Summary ==
>
> After preliminary discussions with CPU vendors, we propose AVX2 as the
> new baseline.  AVX2 support was introduced into CPUs from 2013 to
> 2015. See [
> https://en.wikipedia.org/wiki/Advanced_Vector_Extensions#CPUs_with_AVX2
> CPUs with AVX2].
>
> Along with AVX2, it makes sense to enable certain other CPU features
> which are not strictly implied by AVX2, such as CMPXCHG16B, FMA, and
> earlier vector extensions such as SSE 4.2.  Details are still being
> worked out.
>
>
In the interest of a productive discussion, could we maybe focus on what
the benefits are, both of changing the baseline in general and of enabling
any particular features? As I see it, there are a few classes of relevant
features:

Features like SSE2: enabling SSE2 as the basic floating point mechanism
changes the ABI drastically.  But x86_64 already requires SSE2, so this is
irrelevant.

Things like SSSE3, SSE3, SSE4, AVX1, AVX2, FMA, etc: for the most part,
these accelerate existing algorithms.  I'm sure that someone somewhere has
written an algorithm that requires FMA for enhanced precision, but
otherwise pretty much any code that benefits from any of these features
would work just fine, if slower, without the features.

Things like CMPXCHG16B that change the set of things that can be done on
the CPU.  I could easily imagine programs that use algorithms that
fundamentally depend on CMPXCHG16B.  There is no drop-in replacement.

Things like FSGSBASE that change the way that software interacts with the
kernel.  Don't even get me started on FSGSBASE on Linux.

So I could see a concrete benefit to Fedora from requiring CMPXCHG16B.  If
FSGSBASE were actually supported and widely used, I could see that, too,
but FSGSBASE is not a credible requirement for Fedora since IIRC it's not
supported on Sandy Bridge.  Even Intel seems to consider Sandy Bridge to be
an important CPU to support.

As for the vector features, they're always a moving target.  Even if Fedora
did require AVX2, performance would be left on the table by not using
AVX-512 where avaiable.  (And AVX2 isn't such a great thing anyway given
certain microarchitectures' latency and power issues.)

I think that, for vector extensions, Fedora shouldn't require anything
beyond SSE2 for basic functionality.  Instead, Fedora should figure out
where there are material benefits to using them and find ways to make it
easier for packagers to make them available.  Ideally this would all be
figured out at runtime, but install-time choices could make sense, too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Andrew Lutomirski]

> On Jul 22, 2019, at 1:21 PM, Solomon Peachy  wrote:
>
>> On Mon, Jul 22, 2019 at 04:11:32PM -0400, Stephen Gallagher wrote:
>> With my FESCo hat on, I can't support this action as currently stated.
>> I think I'd be more inclined to consider it if the Change was proposed
>> as a new architecture bring-up. Effectively, this would be a whole new
>> architecture that would just happen to be largely compatible with
>> x86_64.
>
> Now that approach makes a lot more sense!
>
> And we could easily do some apples-to-apples system benchmarks to see if
> there's any meaningful improvements to be had.
>

IMO this approach is wrong. There’s nothing special about AVX1.  There
are plenty of packages that can be built with various CPU extensions
on or off but that don’t have runtime detection. and Fedora should
have the ability to straightforwardly build multiple variants. Sure,
this might involve some rpm and dnf fiddling, but that’s nothing
compared to creating a whole new architecture.

I can imagine this working in multiple ways.  There could be something
akin to modules or maybe sub-architectures, where there are multiple
non-parallel-installable versions of various packages along with
tooling to say "optimize for this machine" or "optimize for the
following baseline".  There could also be good tooling to build
dynamically-selected libraries (/lib/hw/avx2/libfoo.so).  Fat binaries
for actual executables or some equivalent (multiple binaries with
/usr/bin/foo choosing which one to exec) could work.  Some combination
could make sense.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Updating/rebuilding of coin-or packages

[Andrew Lutomirski]

On Mon, Apr 15, 2019 at 7:35 PM Jerry James  wrote:

> On Mon, Apr 15, 2019 at 12:00 PM Antonio Trande 
> wrote:
> > On 15/04/19 19:25, Andrew Lutomirski wrote
> > > Would one of you be interested in maintaining coin-or-lemon?  I
> packaged
> > > it because I thought I was going to use it, but I ended up not using
> it.
> >
> > Add me, please.
> > My FAS: sagitter
>
> I can comaintain too, if you like.  FAS: jjames.
>
>
Done.  Thanks!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Updating/rebuilding of coin-or packages

[Andrew Lutomirski]

On Mon, Apr 8, 2019 at 9:33 PM Jerry James  wrote:

> Hi Antonio,
>
> On Mon, Apr 8, 2019 at 12:26 PM Antonio Trande 
> wrote:
> > Hi all.
> >
> > Updates of coin-or-Sample/CoinUtils/Ipopt packages are coming on
> > Rawhide; involved packages:
>
> I didn't know you were working on this.  I noticed a week or so ago that
> several of the coin-or packages have FTBFS bugs filed against them, so I
> started working on fixing and updating all of them.  I had to stop due to a
> trip out of town, but I got through about 4/5 of the coin-or packages, with
> various improvements.  Are you interested in seeing what I've got, or would
> you rather just go ahead with what you've already done?  Here is a summary
> of what I've done so far, in the approximate order in which the packages
> would have to be built.
>
>- coin-or-Data-miplib3: new package (
>https://bugzilla.redhat.com/show_bug.cgi?id=1693913)
>- coin-or-Data-Netlib: new package (
>https://bugzilla.redhat.com/show_bug.cgi?id=1693514)
>- coin-or-Ipopt: update to 3.12.12, correct license to "EPL-1.0", drop
>unnecessary BRs and Rs
>- coin-or-Sample: update to 1.2.11, drop unnecessary pkgconfig R
>- coin-or-CoinUtils: update to 2.11.1, correct license to "EPL-1.0",
>change URL to github, add a patch to prevent a segfault when a problem's
>status has not been set (need to send that upstream), kill rpath
>- coin-or-Osi: update to 0.108.3, correct license to "EPL-1.0", change
>URL to github, add patch to build with glpk >= 4.48 (see
>https://github.com/coin-or/Osi/pull/121), kill rpath, drop unnecessary
>BRs and Rs
>- coin-or-Clp: update to 1.17.1, correct license to "EPL-1.0", change
>URL to github, add bootstrap conditional due to circular build dependencies
>with Cbc, build with MUMPS and suitesparse support, build with Cbc and
>nauty support on the non-bootstrap build, add patch to fix a bad static
>cast, add patch to fix a crash in coin-or-lemon, add patch to fix a bad
>parameter when building with Cbc support
>- coin-or-DyLP: update to 1.10.4, correct license to "EPL-1.0",
>install and set the path to the error text message file, kill rpath, drop
>unnecessary BRs and Rs
>- coin-or-Vol: update to 1.5.4, correct license to "EPL-1.0", kill
>rpath, drop unnecessary BRs and Rs
>- coin-or-Cgl: update to 0.60.1, correct license to "EPL-1.0", change
>URL to github, kill rpath, drop unnecessary BRs and Rs
>- coin-or-Cbc: update to 2.10.1, correct license to "EPL-1.0", change
>URL to github, add patch to fix failure to link with glpk, build with nauty
>support, drop unnecessary BRs and Rs
>- coin-or-SYMPHONY: update to 5.6.17, correct license to "EPL-1.0",
>change URL to github, provide the PDF manual, drop unnecessary BRs and Rs
>- coin-or-Alps: update to 1.5.7, correct license to "EPL-1.0", change
>URL to github, kill rpath, drop unnecessary BRs and Rs
>- coin-or-Bcp: update to 1.4.4, kill rpath, drop unnecessary BRs and Rs
>- coin-or-CoinMP: update to 1.8.4, kill rpath, drop unnecessary BRs
>and Rs
>- coin-or-FlopC++: update to 1.2.5, correct license to "EPL-1.0",
>update URL, add -doc subpackage with doxygen output, kill rpath, drop
>unnecessary BRs and Rs
>- coin-or-lemon: add patch to fix template problem (causes FTBFS), add
>patch to fix test failures due to references to temporary objects that go
>out of scope, fix the cmake file to refer to a shared library, kill rpath
>- coin-or-Bcps: correct license to "EPL-1.0", change URL to github,
>kill rpath, drop unnecessary BRs and Rs
>- coin-or-Blis: update to 0.94.8, correct license to "EPL-1.0", change
>URL to github, drop unnecessary BRs and Rs
>
> That's as far as I've gotten.  I haven't looked at coin-or-Bonmin,
> coin-or-Couenne, coin-or-Dip, or coin-or-OS yet.  Let me know if you would
> like to see all these changes first, or proceed with what you have planned
> first.
>
>
Would one of you be interested in maintaining coin-or-lemon?  I packaged it
because I thought I was going to use it, but I ended up not using it.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Any plans to support .heic files in Fedora?

[Andrew Lutomirski]

On Mon, Dec 3, 2018 at 3:56 PM Leigh Scott  wrote:

> > On 11/30/18 5:20 AM, Leigh Scott wrote:
> >
> > Thanks Leigh. I see those have already made progress in code review.
> +1000
> >
> > Is there a definitive reason why those are necessary to go in RPM
> fusion? Was
> > Tom Hughes right?
> >
> > Dusty
>
> This sums up the situation
>
>
> http://gnome-apps.13852.n7.nabble.com/High-Efficiency-Image-File-Format-HEIF-HEIC-support-td70229.html


IANAL, and I know basically nothing about codec patents, but it might be
worth noting that there are a whole bunch of video coding techniques that
are presumably completely unnecessary for decoding video *stills*, i.e.
I-frames.  Things like motion compensation are irrelevant if there's no
motion.

So it's at least slightly plausible that any patents in question wouldn't
apply to a heavily stripped down decoder that only implemented the parts of
the spec needed to decode HEIF.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Proposal: Faster composes by eliminating deltarpms and using zchunked rpms instead

[Andrew Lutomirski]

> On Nov 23, 2018, at 6:16 AM, Florian Weimer  wrote:
>
> * Jonathan Dieter:
>
>>> On Tue, 2018-11-20 at 12:45 +, Michael Schroeder wrote:
 On Mon, Nov 19, 2018 at 08:30:14PM +, Jonathan Dieter wrote:
 Just to be clear on this, unlike deltarpm, zchunked rpms shouldn't
 require extra CPU usage on the client side as they don't go through the
 decompress-recompress cycle that deltarpms do.  Re-assembling a zchunk
 file requires no compression or decompression.
>>>
>>> Btw, we can easily do that for deltarpms as well. We only recompress
>>> because we want a rpm that is bit-identical to the remote one.
>>>
>>> Having a '-u' option that makes applydeltarpm write a rpm with an
>>> uncompressed payload and no payload signatures is just a couple of
>>> lines of code.
>>
>> But the problem is that you would lose the signatures.  To make this
>> work, we would need to create signatures of both the compressed and
>> uncompressed rpm (which wouldn't be a bad idea).  Is there some way we
>> could (ab)use the current rpm format to make this work, or would it be
>> a backwards-incompatible change?
>
> The problem is that the RPM header hash covers quite a few fields that
> change if the payload compression changes.  I'm not even sure if the
> compressed payload itself is hashed.
>
> IIRC, primary.xml only contains compressed payload hashes, not the
> header hash, so if we cannot reproduce the compressed payload, then the
> hashed chain from the centralized mirror manager to the individual RPM
> packges is broken.  This hash chain is very much needed for security
> because RPM signing itself is quite broken.
>

This does suggest a solution: don’t even bother checking RPM
signatures for RPMs that come from Fedora, at least in deltarpm mode.
Instead, fix the repodata signing and just check that.  primary.xml
could gain a signature of the uncompressed rpm if that would make key
management easier.

As another way of looking at this, the model where one expects:

# rpm -e package.rpm

to validate a signature and therefore only install safe packages is
inherently broken, since it cannot protect against forced downgrades.
Instead, the model that works, or at least can work, is for:

# dnf install package

to validate whatever needs to be validated.  So it seems entirely
reasonable to me that dnf could gain a new, better way to validate
package freshness and authenticity, and then dnf could pass
--nosignature or the equivalent to rpm when installing a package.
This way Fedora would keep compatibility with foreign rpms, but Fedora
could also avoid expensive recompression when using delta rpms.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

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

[Andrew Lutomirski]

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

https://bugzilla.redhat.com/show_bug.cgi?id=1633814

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.  And it also seems like it might be
surprising for a remove-and-reinstall of nvme-cli to generate a whole
new NQN.

Maybe /etc/machine-id could just be symlinked to /etc/nvme/hostnqn.
Or maybe the user should be responsible for setting it up themselves.
Or maybe installing nvme-cli could create an NQN but uninstalling
could leave it there?

Is there any guidance for how to handle this?

Debian has "purge" for things like this, but I don't think Fedora has
any equivalent.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

[Andrew Lutomirski]

On Jul 30, 2018, at 10:42 AM, Andrew Lutomirski  wrote:


On Jul 27, 2018, at 9:58 AM, Owen Taylor  wrote:

On Fri, Jul 27, 2018 at 9:44 AM, Florian Weimer  wrote:

> On 07/27/2018 03:33 PM, John Reiser wrote:The key principle is that
> sizeof(foo) must be the stride of an array of foo,
>
> and the array must guarantee alignment of each element in the array.
>>
>
> Why do you think that?  If some documentation claims this is the case for
> individual objects, we need to fix it.


struct sizes *do* have this property - they are rounded up so that arrays
have the correct alignment.
But that certainly doesn't imply that malloc(7) is allowed to give you
unaligned memory.



As an x86 person but only occasionally a standardese person, I find the
idea that malloc(8) should return a 16-byte-aligned pointer on x86 to be
nuts. I can only think of one non-UB way to notice the difference between
an 8-byte and 16-byte aligned result, and that way would be to literally
cast to (u)intptr_t and look at the low bits.  This is plausibly relevant
to certain VMs and tag bit users, but is totally irrelevant to basically
anything else.  And 16-byte alignment for small allocations is a giant
waste of memory.

So I think that glibc should change its behavior here to match everyone
else, and get the ABI document changed if needed.

Frankly, I find it a bit odd that C stack frames on x86_64 want 16 byte
alignment, and it took until gcc 4.8 (IIRC) to get proper support to opt
out.


I did some research. Windows (via the VS runtime) gives the largest
alignment of a non-overaligned object *that could fit in the allocated
space*. See:

https://docs.microsoft.com/en-us/cpp/build/malloc-alignment

OpenBSD’s manual is unclear.

musl appears to give 4*sizeof(size_t) alignment no matter what.  This makes
no sense to me.

FreeBSD’s manpage is the same as OpenBSD’s, but its malloc *is* jemalloc
AFAICT.

POSIX.1-2008 says “The pointer returned if the allocation succeeds shall be
suitably aligned so that it may be assigned to a pointer to any type of
object and then used to access such an object in the space allocated (until
the space is explicitly freed or reallocated).”  As far as I can tell, they
mean any type of object whose size matches the argument to malloc.  This
definition, taken literally, is odd: if you define a type with size 1 and
alignment 8192, it’s not going to work. So either POSIX intends to restrict
itself to types that don’t involve truly wacky compiler extensions or to
types that can exist as array members, such that alignment divides the
size. In that case, glibc’s malloc is more strictly aligned than POSIX
requires.

Here's an article about Firefox's experience:
http://www.erahm.org/2016/03/24/minimum-alignment-of-allocation-across-platforms/

ISTM glibc is going a bit overboard here.  I can see some very minor
benefits to forcing 16-byte alignment for small allocations, but it comes
at the obvious cost of 2x memory overhead for 8-byte allocations and 4x for
4-byte allocations.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GAI4XYKGPNJKOZAO2LLFZ3GOZLAWKBZC/

Re: F29 System Wide Change: Remove Excessive Linking

[Andrew Lutomirski]

> On Aug 2, 2018, at 2:57 AM, Jakub Jelinek  wrote:
>
>> On Thu, Aug 02, 2018 at 11:45:00AM +0200, Dominique Martinet wrote:
>> Wearing a lib developer hat, I don't see how you can make a .pc that
>> doesn't overlink if you provide something a bit entangled with other
>> libs.
>> The problem is that if your headers use any sub-lib type you need to add
>> that lib in Requires: so that --cflags will pull that lib's include
>> path; and that will in turn add that sub-lib to the linked libs even if
>> the program likely doesn't care about it (either because they didn't
>> even use that part of your lib, or because all uses of that lib will be
>> done through your own anyway so it wasn't required in the first place)
>
> Then it is clearly a task for pkg-config (and libtool) to handle it better.
> If the --libs it provides contains some mandatory and some optionally needed
> libraries, then it should differentiate between them and use
> -Wl,--push-state,--as-needed ... -Wl,--pop-state
> around those that are optionally needed.  If all libraries from those tools
> are optional, perhaps it should use it always.
>
> Changing the behavior of say -lpthread on the command line is a bad idea,
> many projects really expect it to mean that the mentioned library is linked
> in and if it no longer does, it causes silent breakage.  Forcing users to do
> -Wl,--push-state,--no-as-needed ... -Wl,--pop-state
> whenever they really mean to link some library is too hostile.

Maybe pkg-config could learn to push state and use —as-needed?  Some
explicit options in gcc and ld like —link-as-needed=libname and
—always-link=libname would be nice, too.  It seems that the toolchain
folks (like you) want -lpthread and the like to keep working, and the
package people want a sane default where symbols are made available
but the DT_NEEDED entry is only used if needed.

On the other hand, switching to as-needed linking seems like it's a
step in the right direction in general, but ISTM it would be much
nicer to switch to as-needed direct binding.  Do glibc and binutils
even support Solaris-style direct binding yet?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/G56MSHDO6IYQSVQ6RKOH2RASL2N4OIZZ/

Re: Guideline change: glibc malloc as the C/C++/Rust allocator

[Andrew Lutomirski]

On Jul 27, 2018, at 9:58 AM, Owen Taylor  wrote:

On Fri, Jul 27, 2018 at 9:44 AM, Florian Weimer  wrote:

> On 07/27/2018 03:33 PM, John Reiser wrote:The key principle is that
> sizeof(foo) must be the stride of an array of foo,
>
> and the array must guarantee alignment of each element in the array.
>>
>
> Why do you think that?  If some documentation claims this is the case for
> individual objects, we need to fix it.


struct sizes *do* have this property - they are rounded up so that arrays
have the correct alignment.
But that certainly doesn't imply that malloc(7) is allowed to give you
unaligned memory.



As an x86 person but only occasionally a standardese person, I find the
idea that malloc(8) should return a 16-byte-aligned pointer on x86 to be
nuts. I can only think of one non-UB way to notice the difference between
an 8-byte and 16-byte aligned result, and that way would be to literally
cast to (u)intptr_t and look at the low bits.  This is plausibly relevant
to certain VMs and tag bit users, but is totally irrelevant to basically
anything else.  And 16-byte alignment for small allocations is a giant
waste of memory.

So I think that glibc should change its behavior here to match everyone
else, and get the ABI document changed if needed.

Frankly, I find it a bit odd that C stack frames on x86_64 want 16 byte
alignment, and it took until gcc 4.8 (IIRC) to get proper support to opt
out.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/5MHUB6W7TX576QQQSHAHLUFBZJKVJBXE/

Re: [HEADS UP] Removal of GCC from the buildroot

[Andrew Lutomirski]

>>> On Jul 15, 2018, at 5:47 AM, Richard W.M. Jones  wrote:
>>>
>>> On Fri, Jul 13, 2018 at 04:05:42PM +0200, Mikolaj Izdebski wrote:
>>> On 07/12/2018 10:17 PM, Richard W.M. Jones wrote:
>>> Does each build start with its own fresh VM?  Do you care about the
>>> data in that build VM if either qemu or the host crashes?  If the
>>> answers are 'Yes' and 'No' respectively to these questions then IMHO
>>> this is the ideal situation for cache=unsafe.
>>
>> The answers are 'No' and 'Not much'.
>>
>> 1. VMs are installed once and are running for week/months until they are
>> reinstalled. In the meantime guests and hosts are rebooted during
>> routine maintenance, to apply updates.
>
> In this case my preferred advice would be: DO NOT use cache=unsafe.
>
> We've only tested scenarios for very short-lived build or temporary
> VMs (for example when I was building RISC-V packages before we had
> Koji, I used a script which created a VM per build and there it made
> sense to use cache=unsafe).
>
> I do not think it's a good idea to be using this for VMs which are in
> any way long-lived as there could be unforeseen side effects which I'm
> not aware of and certainly have never tested.
>
>> 2. There would be no data loss in case of host or hypervisor crash.
>> Worst case, if guest operating system was corrupted sysadmins would need
>> to trigger VM install.
>
> Host crash => yes you'd definitely need to reinstall that VM.
>
> It's not a worst case, a host crash would near-definitely corrupt a VM
> that was ignoring flush requests.  It might even corrupt in an
> undetectable way (eg. throwing away data while leaving metadata
> intact).

Would it make sense to boot the builders with -snapshot and
cache=unsafe?  After all, during normal operation, they don’t need to
persist anything.

It might even be reasonable to reboot the VMs after every single build.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EX4K4RQ6MUVLEHK6JWXDOZ7UCTSJUI6H/

Re: [HEADS UP] Removal of GCC from the buildroot

[Andrew Lutomirski]

> On Jul 12, 2018, at 4:26 AM, Simo Sorce  wrote:
>
>> On Thu, 2018-07-12 at 07:32 +, Petr Pisar wrote:
>>> On 2018-07-11, Zbigniew Jędrzejewski-Szmek  wrote:
>>> The effects of fsync are impossible to see unless you hard-reboot
>>> the
>>> machine.
>>
>> Are you sure non-fsynced changes are are guaranteed to be visible on
>> block cache level? E.g. if you mix read/write and mmaped I/O from
>> different processes?
>
> In linux file writes and memory writes all hit the unified page cache
> so there is not difference at all, only direct io skips the page cache
> IIRC (but it should also invalidate it, so again no issues to
> applications).
>
> fsync only really make sure that what's in memory is pushed down to
> disk and is safely on permanent storage (which is a lie with some
> storage, but that is a different problem).
>
>>> I wonder if it wouldn't be more robust to use nspawn's syscall
>>> filter to filter the fsync calls.
>>
>> Can the syscall filter fake a success of the syscall return value?
>> Correctly written applications check fsync() return value and forward
>> the error.
>
> No, nspawn's filter just uses seccmop filters, which return
> EINVAL/EPERM (IIRC) on blocked arguments/syscalls
>
> So it is indeed not appropriate to use nspawn's filters to block
> fsync()

Seccomp can be used to block a syscall and fake a return value of 0
(success) or any error code chosen by the filter.  I assume systemd
exposes this functionality.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HKZQG4BJ4RRVVHOAI5GOJYG3DCZVRARE/

Re: [HEADS UP] Removal of GCC from the buildroot

[Andrew Lutomirski]

On Wed, Jul 11, 2018 at 10:08 AM, Mikolaj Izdebski  wrote:
>
> On 07/11/2018 06:37 PM, Andrew Lutomirski wrote:
> > From my perspective as an occasional Fedora packager, I'm regularly
> > surprised by just how long it takes for Koji builders to install
> > dependencies.  I've never tried to dig in too far, but it looks like the
> > builders download package metadata, download packages, and then install
> > things.  Surely this could be massively optimized by having the metadata
> > pre-downloaded (at least when side tags aren't involved) and by having the
> > packages already present over NFS or similar.
>
> Koji gets repodata and packages from HTTP servers, through caching
> proxies located in the same datacenters as builders. Most often used
> packages are cached in memory, so download speeds are not a problem. At
> least for non-s390x builders. Accessing packages directly from NFS would
> be slower.
>

I wonder if the time taken to decompress everything is relevant.
Fedora currently uses xz, which isn't so fast.  zchunk is zstd under
the hood, which should be lot faster to decompress, especially on ARM
builders.

>
> The slowest parts of setting up chroot is writing packages to disk,
> synchronously. This part can be speeded up a lot by enabling nosync in
> site-defaults.cfg mock config on Koji builders, setting cache=unsafe on
> kvm buildvms, or both. These settings are safe because builders upload
> all results to hubs upon task completion. With these settings chroot
> setup can take about 30 seconds.


I don't suppose this could get done?

>
>
> Once this is optimized, another slow part is loading repodata into
> memory - uncompressing it, parsing and creating internal libsolv data
> structures. This could be speeded up by including solv/solvx files in
> repodata, but I think that would require some code changes.


Hmm.  On my system, there are lots of .solv and .solvx files in
/var/cache/dnf.  I wonder if it would be straightforward to have a
daily job that updates the builder filesystem by just having dnf
refresh metadata and generate the .solv/.solvx files?  There wouldn't
be any dnf changes needed AFAICT -- just some management on the
builder infrastructure.  This would at least avoid a bunch of
duplicate work on most builds.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JFLPBDPLIPH6WPH3LYUMV2BAB2O3C3ZJ/

Re: [HEADS UP] Removal of GCC from the buildroot

[Andrew Lutomirski]

On Tue, Jul 10, 2018 at 1:13 PM, Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Jul 10, 2018 at 06:03:33PM +0200, Igor Gnatenko wrote:
> > On Tue, Jul 10, 2018 at 5:52 PM Kevin Kofler 
> wrote:
> >
> > > Igor Gnatenko wrote:
> > > > As per Changes/Remove GCC from BuildRoot
> > > > ,
> I'm
> > > > going to automatically add BuildRequires: gcc and/or BuildRequires:
> > > > gcc-c++ to packages which fail to build with common messages (like
> gcc:
> > > > command not found, also autotools/cmake/meson are supported).
> > > >
> > > > I'm going to do this tomorrow.
> > > >
> > > > After which, I'm going to ask rel-eng to finally remove it from
> > > buildroot.
> > > > This will happen before mass rebuild. Stay tuned.
> > >
> > > I still think that this change is absolutely counterproductive,
> because it
> > > will actually INCREASE local mock build times for all C/C++ programs
> for
> > > all
> > > packagers, because gcc and gcc-c++ will no longer be included in the
> root
> > > cache.
> > >
> >
> > However, it will DECREASE local mock build times for all non-C/C++
> > programs. And now we will know which packages actually need C and/or C++
> > compiler.
>
> Yes.
>
> Also, we'll have a mass rebuild tomorrow. If it turns out to be slower
> than the previous one, we can easily re-add gcc to the koji buildroot.
>
>
>From my perspective as an occasional Fedora packager, I'm regularly
surprised by just how long it takes for Koji builders to install
dependencies.  I've never tried to dig in too far, but it looks like the
builders download package metadata, download packages, and then install
things.  Surely this could be massively optimized by having the metadata
pre-downloaded (at least when side tags aren't involved) and by having the
packages already present over NFS or similar.

>From a design perspective, minimizing the contents of the buildroot is a
good idea, I think, but I think it would be great if the runtime
installation of dependencies during the package build process were sped up
dramatically.

(Hmm.  Some future version of rpm/dnf could get really fancy and *reflink*
package contents into the build chroot rather than untarring them every
time.)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/O4JOXTWWBNHZF7F4W4LXPEA72B2WLWY3/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Andrew Lutomirski]

> On Jun 25, 2018, at 3:40 AM, Lennart Poettering  wrote:
>
>> On Fr, 22.06.18 14:17, Chris Murphy (li...@colorremedies.com) wrote:
>>
>> On Fri, Jun 22, 2018 at 12:57 PM, Lennart Poettering
>>  wrote:
>>> On Fr, 22.06.18 19:01, Javier Martinez Canillas (jav...@dowhile0.org) wrote:
>>>
> Whereas constantly changing the ESP, means we need some way to
> establish a master and rsync to the extras.

 So the consensus seems to be to have the BLS fragments in
 $BOOT/loader/entries even on EFI, where $BOOT is the boot partition
 mounted on /boot. That will give us the following advantages as
 mentioned in this thread:
>>>
>>> Uh, as one of the authors of the spec, I am not convinced using
>>> arbitrary non-FAT file systems for $BOOT. In fact the spec currently
>>> says it has to be VFAT. I wouldn't call that "consensus".
>>
>> Lennart, I sympathize, but face it. There is a single implementation
>> of kernels and initramfs on the ESP and that's systemd-boot. Everyone
>> else wants to get as far away from vfat as fast as possible. For a
>
> I am not sure why you are making this about systemd-boot. Let's just
> focus on why (or why not) vfat is the best option for $BOOT.
>
>>> Which file system do you have in mind even for this?
>>
>> Unspecified for now. i.e. no change. It would remain ext4 by default I
>> expect, but ultimately whatever anaconda allows.
>
> So think about this one bit ahead. Right now it's clear that even with
> Grub's relatively large contributor base it'shard to impossible to
> support modern Linux file systems properly — even just for
> read-only. See the the XFS debacle as one example, and that the kernel
> folks made clear they only consider their own in-kernel implementation
> to be supportable. Now, I'd assume that sooner or later features such
> as boot counting are something we want for Fedora too (i.e. that we
> can update the kernel, try to boot the new one a couple of times, and
> when it fails all the time revert back to an older version, fully
> automatically; in fact the fedora desktop have very recently started
> work on that, though they have a weaker model of simply showing the
> boot menu after failed boots, instead of reverting back). Now, in that
> model you need to count the attempted boots somewhere. Thus you need
> write access somewhere (and no, EFI variables don't work for this,
> they are not suitable for stuff changed on every boot, as their memory
> is generally not ready to be written too that often). Which hence
> means you need write access to some file system in some form from the
> boot loader. And how do you think that's going to work out if already
> read access to modern file systems is, well, a desaster?
>
> Again, FAT is the one thing everyone can agree on. Boot loaders can
> read it *and write it*, UEFI and raspberry pi firmwares have support
> for it, and all OSes and their initrds generally too.
>
> From the Linux side we can provide relatively safe read and write
> suppport for FAT. For example, if Fedora would use the systemd
> automount logic for mounting $BOOT then the file system will generally
> be unmounted, except in a small time window around actual
> accesses. This means the chance that the file system remains in a
> clean state is maxmized.
>
> $BOOT is a place to place very few files, with very simple access
> patterns. Basically, during update cycles we just add a few files
> there and remove some others, and they are written in one linear write
> operation. For doing that we need no fancy file system features. The
> simplest, most common file system storing files ist good enough for
> that.

You’ve done a great job stating requirements, but I think you’ve drawn
the wrong conclusion based on the requirements. I’ll summarize:

(a) The bootloader needs to be able to read $BOOT.

(b) It would be nice if UEFI's filesystem layer supported $BOOT. (You
would prefer if it were baked into firmware.  Others might debate this
requirement.)

(c) $BOOT needs to be written when new kernels are installed.

(d) It is useful to write to $BOOT from the bootloader to indicate
that we're trying to boot and again from the booted system to indicate
that the boot succeeded.

(e) Writing $BOOT should be safe.  (You said "relatively safe".  I
would argue that "as safe as possible against power failure and kernel
panics" is better.)

Let's also add:

(f) The scheme should function without UEFI.  There are plenty of
non-UEFI systems out there.  This means that the bootloader might need
to live in a BIOS boot partition, or in flash, or in ROM, or in other
strange places.

(g) The bootloader's driver for $BOOT should implement at least reads
and preferably writes compatibly with the kernel.  (With the possible
exception of F2FS, there are no crash-safe filesystems that meet this
requirement, sadly.)

(h) Putting $BOOT on RAID1 is extremely nice to have.


Now let's think this through.  You're proposing that $BOOT be the ESP.
This fails (f) 

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Andrew Lutomirski]

> On Jun 25, 2018, at 3:54 AM, Daniel P. Berrangé  wrote:
>
>> On Mon, Jun 25, 2018 at 12:47:35PM +0200, Lennart Poettering wrote:
>>> On Mo, 25.06.18 11:23, Daniel P. Berrangé (berra...@redhat.com) wrote:
>>>
>>> That would break applications like libguestfs which run as non-root and
>>> have valid need to access /boot/vmlinuz*
>>
>> Hmm, can you elaborate on that? What precisely do they need there?
>
> libguestfs boots a KVM guest to do its work inside and uses the installed
> kernel image from /boot/vmlinuz-$UNAME_R for this purpose, together with
> a custom initrd image with specific modules + specialized init binary.

As does virtme.  I just added support for /usr/lib/modules to virtme.
Thanks for the pointer.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QIXTUMKAJW437VO65BCV65ESTHTO7V6L/

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Andrew Lutomirski]

> On Jun 18, 2018, at 3:54 PM, Chris Murphy  wrote:
>
> On Mon, Jun 18, 2018 at 3:42 PM, Andrew Lutomirski  wrote:
>>> On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas 
>>>  wrote:
>
>>> Yes for EFI systems but no otherwise. On EFI the BLS snippets are in
>>> /boot/efi/EFI/fedora/loader/entries and on non-EFI systems are in
>>> /boot/loader/entries.
>>>
>>
>> I think this is the wrong approach. I see no valid reason that the
>> paths should be different on EFI.
>
> I don't like it either but I'm trying to keep an open mind. What I
> recall from the conversations years ago with the mgj59 variant, it's a
> lot easier to poke holes in any attempt to standardize bootloading,
> than to standardize bootloading. But if no one is willing to give any
> ground anywhere, it's way too easy to stop progress.
>
> The proposed change doesn't really fix any of the user facing
> problems, it just gets us away from depending on grubby and
> grub-mkconfig (we never really depended on grub-mkconfig, the
> installer uses it as a one shot). So in the most narrow sense, the
> change succeeds at doing the only thing it's intending to do. But
> yeah, I lament that we're not being more aggressive while we have the
> chance to fix past oversights.
>
>

And that's fine, as long as it's not done in a way that makes it
harder to improve in the future.

>>>
>>>> If there's no room on the EFI System partition for all of this, will
>>>> we following bullets 2 and 5 of the BLS spec under "The installer
>>>
>>> No, $BOOT is always the ESP where GRUB 2 is installed.
>>
>> I’m going to go out on a limb and make a stronger objection than
>> Chris’: I think that $BOOT SHOULD NOT be the ESP. The ESP is
>> problematic for any number of reasons. It’s usually vfat, so it’s
>> fragile. It does not support RAID safely. And it’s often small.
>
> Well as it turns out all the file systems are fragile as far as the
> bootloader is concerned :-P We've got bugs where the bootloader can't
> read needed files, because part of the commit is still in the journal
> rather than fully flushed out to file system metadata. So no matter
> what you can break a set up...
>

...

>
> Getting journal support in the bootloader isn't going to happen. I've
> already talked to the various fs upstreams about it.
>

Why are you talking to the fs upstreams?  The problem is a bug in
GRUB, full stop. All this freeze crap that Fedora does is just
papering over the bug.  IMO the right thing to do is to get *GRUB*
upstream to have a fully functional implementation of *one*
widely-supported fs.  Hmm, GRUB supports F2FS, and F2FS is
log-structured, right?  So I don't see how GRUB could fail to read a
dirty filesystem correctly even if it wanted to.

Or someone could design a very simple, highly reliable, filesystem
designed to make it easy to do atomic-enough updates and to read
reliably.  Think VFAT-like but with a full atomic swap of all FS
metadata.  Or a dead-simple log-structured FS.  /me ducks.

Seriously, though, F2FS might be a fantastic choice for this purpose.

>
>> As an extra plus, upgrading a kernel doesn’t require mounting the ESP,
>> which means that the bootloader installation can sync the ESP across
>> multiple disks and it will remain synced.
>
> Yeah. But *le sigh* we have fwupd which wants /boot/efi mounted
>
> I use 'umask=0077,shortname=winnt,nofail,noauto,x-systemd.automount'
> in fstab for /boot/efi and yet every boot:
>
> Jun 17 14:07:06 f28h.local systemd[1]: boot-efi.automount: Got
> automount request for /boot/efi, triggered by 2268 (fwupd)
>
> So add that to the list of packages that need an ESP syncing daemon if
> they don't want to be responsible for dynamically mounting and
> umounting the ESP.

I disagree.  fwupd doesn't need any ESP syncing.  In the very worst
case, fwupd sticks a capsule in the ESP from which we booted, then
that disk dies, and we don't apply the capsule.  No harm done.

I really think the correct approach here is to have an ESP on each
potentially bootable disk.  Each ESP will independently contain the
code to handle BootLoaderSpec entries on a *different* partition.  The
only time we need to modify all the ESP copies is when we upgrade GRUB
or upgrade GRUB's configuration.  We do *not* need to propagate
capsules or any other similar objects.  And we should not even try to
impose a requirement that the filesystems be bitwise identical.
They're *copies*, not RAID.

>
>
>> All that being said, $BOOT should not use security context xattrs —
>> getting that to work right across distros is probably impossible.
>
>
> It's a good point. I'm not really sure  how to prevent conflicts if
> t

Re: F29 System Wide Change: Make BootLoaderSpec the default

[Andrew Lutomirski]

> On Jun 18, 2018, at 10:02 AM, Javier Martinez Canillas  
> wrote:
>
>> On Thu, Jun 14, 2018 at 10:20 PM, Chris Murphy  
>> wrote:
>> On Thu, Jun 14, 2018 at 12:51 PM, Adam Williamson
>>  wrote a monolithic config
>

>
>> The cited BLS spec requires $BOOT be VFAT, are we doing that?
>>
>
> Yes for EFI systems but no otherwise. On EFI the BLS snippets are in
> /boot/efi/EFI/fedora/loader/entries and on non-EFI systems are in
> /boot/loader/entries.
>

I think this is the wrong approach. I see no valid reason that the
paths should be different on EFI.

>
>
>> If there's no room on the EFI System partition for all of this, will
>> we following bullets 2 and 5 of the BLS spec under "The installer
>
> No, $BOOT is always the ESP where GRUB 2 is installed.

I’m going to go out on a limb and make a stronger objection than
Chris’: I think that $BOOT SHOULD NOT be the ESP. The ESP is
problematic for any number of reasons. It’s usually vfat, so it’s
fragile. It does not support RAID safely. And it’s often small.

Most of this can be solved by putting $BOOT on a different partition.
Stick it on mdadm 1.1 if you want RAID (*not* 1.0 or 0.9 due to
corruption risks [0]), and maybe even use a journaling filesystem that
the bootloader can *correctly* read. (That means the bootloader should
be able to parse the journal.).  And make it however big you want.

As an extra plus, upgrading a kernel doesn’t require mounting the ESP,
which means that the bootloader installation can sync the ESP across
multiple disks and it will remain synced.

All that being said, $BOOT should not use security context xattrs —
getting that to work right across distros is probably impossible.

[0] I use mdadm a lot, and I never use 0.9 or 1.0. It’s too fragile.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JURU4F7L5CLTXWINANC2WVTBTRMTE76T/

Re: f29 bootloader changes / raid1 installs + efi

[Andrew Lutomirski]

On Fri, Jun 15, 2018 at 2:58 PM, Tom Hughes  wrote:
> On 15/06/18 22:50, Jason L Tibbitts III wrote:
>>>
>>> "KM" == Kyle Marek  writes:
>>
>>
>> KM> I can't remember what else I discovered in reading the manual
>> KM> last. Do you know if there are any other discovery/identification
>> KM> limitations to the old superblocks?
>>
>> I don't think there are any in the context of having a small RAID1 ESP
>> across not too many devices.  The 0.9 format which anaconda uses is
>> limited to 28 devices (and 4TB, but that's obviously not a problem).  I
>> don't really see why it couldn't use the 1.0 format, really.  There is
>> no difference between the 1.0, 1.1 and 1.2 formats besides the location
>> on the disk.
>
>
> I have a machine that has a raid1 md for the ESP using 1.0 metadata
> and it's never caused any problems.
>
> I didn't realise the installer did it automatically now though - that
> machine was setup when the installer wouldn't even let you do it
> manually so I had to set it up as raid post install.
>

I wouldn't be surprised if using a capsule-on-disk did terrible
terrible things if ESP were on invisible RAID 1 (a la mdadm  0.9 or
1.0).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/26GYAT63UYYLD6HI2EG75G2ES5AP4NN2/

Re: Hiding the grub menu by default on single OS installs

[Andrew Lutomirski]

On Sun, Jun 3, 2018 at 11:05 AM, Hans de Goede  wrote:
> Hi,
>
> On 01-06-18 20:38, Andrew Lutomirski wrote:
>>>
>>> On Jun 1, 2018, at 1:04 AM, Hans de Goede  wrote:
>>>
>>> Hi All,
>>>
>>> First of all I want to thank everyone for their input.
>>>
>>> I also want to make clear that the hide the menu +
>>> not listening for a keypress at all (aka fastboot) is a
>>> Fedora 30 thing, quoting myself:
>>>
>>> "For F29, single OS Fedora Workstation install we get:
>>>
>>> 1) grub menu hidden by default with a 1 second timeout to press ESC
>>> or F8 to show it
>>
>>
>> As discussed, this isn’t so great. Can we at least let users hold down
>> a key rather than having to press it at the correct magic time?
>
>
> Because detecting modifiers with UEFI is iffy and with
> serial consoles is outright impossible.

I think that, if we have a serial console, we should have a minimum
250ms delay or so such that, if I hold down a key, I get a grub menu.
(Does UEFI buffer keystrokes?  It might be sufficient to just check
*once* for buffered keystrokes.)  On systems where I have a serial
console, I want to be able to rescue the system, full stop.

On UEFI, we should at least try, I think.  And checking once for
buffered keystrokes would be really nice too.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7M2UKNHYECMNPPD5IFCKFKXLYDPPL3XK/

Re: Hiding the grub menu by default on single OS installs

[Andrew Lutomirski]

> On Jun 1, 2018, at 1:04 AM, Hans de Goede  wrote:
>
> Hi All,
>
> First of all I want to thank everyone for their input.
>
> I also want to make clear that the hide the menu +
> not listening for a keypress at all (aka fastboot) is a
> Fedora 30 thing, quoting myself:
>
> "For F29, single OS Fedora Workstation install we get:
>
> 1) grub menu hidden by default with a 1 second timeout to press ESC
> or F8 to show it

As discussed, this isn’t so great. Can we at least let users hold down
a key rather than having to press it at the correct magic time?

> 2) grub menu shown with 5 sec timeout after a failed boot
>
> For F30, single OS Fedora Workstation install install we get:
>
> 1) grub menu not shown, 0 second timeout, no way to get to the menu
> 2) grub menu shown with 5 sec timeout after a failed boot"
>

I think this is a severe regression.  There are multiple use cases
that you’re breaking:

1. Nothing failed per se, but I want to test a boot option.  I
shouldn’t need to reconfigure grub.

2. The system booted successfully but is unusable (due to a graphical
glitch caused by a kernel regression, a lost driver due to a dracut
issue, or maybe some filesystem issue causing login to fail or the
session post-login to be unusable).  It would be fixable by booting an
older kernel or entering an appropriate recovery mode, but if the menu
is entirely gone, then it can’t.

3. The boot failed outright and the “failed boot” logic is busted.

I think this is asking for far more trouble than the benefit is worth.
I’m not on FESCo, but if I were, I would definitely vote -1.

Please at least do the bare minimum and teach grub to notice that some
key is held down and show the menu in response.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RJIG7KP6L3S2PVH5JJNWXYFLA5OEQ6L6/

Re: F29 System Wide Change: Hide the grub menu

[Andrew Lutomirski]

On Thu, May 31, 2018 at 1:26 PM, R P Herrold  wrote:
>
> I think it was a fair question which was raised about the size
> of the audience being sought to be catered to, vs the mass of
> users of Fedoraproject code, and their 'least astonishment'
> and loss of acquired knowledge as to use
>
> If there are, oh, say, twelve people in the world that
> actually care about instantaneous GUI boots in Fedora, it is a
> waste of time to mess with this thread
>
>
> but to the most recent point raised about 'modifier keys'.  I
> recall doing this back in DOS days with a third-party tool
> that permitted 'BAT files' to query for Shift, Alt, and Ctrl
> key states, and to build boolean decision trees:
>
> On Thu, 31 May 2018, Andrew Lutomirski wrote:
>
>> If the protocol were that the boot menu would be shown if
>> any key at all were held down, then we wouldn't need a 1
>> second delay.
>
> or, perhaps, better still and less complex as in needing to
> suppress a boot menu, a message at the bottom of the GUI
> screen from its first appearance and for ten seconds or so:
> Hold either Shift key for more boot options

More concretely, perhaps plymouth could display such a message on its
splash screen for as long as its running.  But the message should
probably be more accurate, along the lines of "Reboot and hold the
Shift key for more boot options".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQ5BAPZVCGLZ77ONMIWJASXL7WKAYIUW/

Re: F29 System Wide Change: Hide the grub menu

[Andrew Lutomirski]

On Thu, May 31, 2018 at 9:00 AM, Jason L Tibbitts III  wrote:
>> "JK" == Jan Kurik  writes:
>
> JK> 1. Add patches to grub to also make pressing F8 show the menu
>
> One thing I've never really understood is the reason for using such a
> small set of keys to interrupt the boot process.  I seem to recall that
> in older versions (perhaps pre-grub2) the space bar or the cursor keys
> worked.  I also recall at some point that you could just hold down the
> shift key.  More recently I actually thought something was broken
> because I simply couldn't find the magic key (only later finding out
> that it had at some point been limited to just 'Esc').
>
> If we're going to patch grub to expand the set of keys it will watch
> for, is it possible to just expand the set to encompass all keys?  We
> don't really need to make it that hard to find the grub menu, do we?

Yes, please, and for more than just ease of use.  Adding an
intentional 1-second delay to the boot process to give the user the
opportunity to press escape is disappointing.  If the protocol were
that the boot menu would be shown if any key at all were held down,
then we wouldn't need a 1 second delay.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VEWAONS5D6BP54H637IHOKFXXVOF2R4C/

Re: [fesco] Updated FTBFS package policy

[Andrew Lutomirski]

On Sat, May 26, 2018 at 2:51 PM, Till Maas  wrote:
> Hi,
>
> On Sat, May 26, 2018 at 04:27:15PM +0100, Sérgio Basto wrote:
>> On Fri, 2018-05-25 at 15:46 +, Zbigniew Jędrzejewski-Szmek wrote:
>> > Fedora package maintainers,
>> >
>> > FESCo approved an updated policy for packages which fail to build
>> > from
>> > source during mass rebuilds (FTBFS) [1].
>>
>> Please list all candidates packages to be retired , last time Till
>> check was about 2000 IIRC
>
> There is no final list yet. I am currently rebuilding several packages
> to ensure that there is a bug report for each package. The most accurate
> list can be found here:
> https://bugzilla.redhat.com/showdependencytree.cgi?id=1555378_resolved=1
>
> During the F28 rebuild, the process failed to trigger a rebuild for a
> lot of packages. I rebuilt a lot of them a while ago but I missed some,
> too (I guess all packages that were rebuilt after the F26 mass rebuild
> but not for F28). I am rebuilding them now, too. Also I will rebuild
> packages for which a bug report is missing or lacks the log files.
>

Can you check that whatever scripts are doing this work are filing
sensible bug reports?  I got this:

https://bugzilla.redhat.com/show_bug.cgi?id=1582774

which has totally wrong text.  This isn't a Fedora 28 FTBFS -- it's a
Fedora 29 FTBFS.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AVTBO4AFDCUWZ732VZ5SGBRSHDXIGAHK/

Re: Serious problem with SATA LPM in F28 on Lenovo 50 series laptops

[Andrew Lutomirski]

On May 2, 2018, at 9:14 AM, Frantisek Zatloukal  wrote:

Hans,
can't this be affected also by different disk vendors (drive vendor in
Lenovo laptop can vary even in same model) and different firmware of disks?
Also, drive FW is upgradeable in Lenovo laptops.

On Wed, May 2, 2018 at 5:39 PM, Hans de Goede  wrote:

> Hi,
>
>
> On 05/01/2018 10:40 AM, Lorenzo Dalrio wrote:
>
>> Hi,
>> i run fedora 28 on a t450 since it was promoted to beta working with it
>> 8-10 hours per day without any issue.
>>
>> System Information
>>   Manufacturer: LENOVO
>>   Product Name: 20BUS003IX
>>   Version: ThinkPad T450
>>
>> # cat /sys/class/scsi_host/host*/link_power_management_policy
>> med_power_with_dipm
>> med_power_with_dipm
>> med_power_with_dipm
>>
>> === START OF INFORMATION SECTION ===
>> Model Family: SanDisk based SSDs
>> Device Model: SanDisk SD7UB3Q256G1001
>> Serial Number:153446402316
>> LU WWN Device Id: 5 001b44 ec5b3450c
>> Firmware Version: X2240501
>> User Capacity:256,060,514,304 bytes [256 GB]
>> Sector Size:  512 bytes logical/physical
>> Rotation Rate:Solid State Device
>> Form Factor:  2.5 inches
>> Device is:In smartctl database [for details use: -P show]
>> ATA Version is:   ACS-2 T13/2015-D revision 3
>> SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
>> Local Time is:Tue May  1 08:39:01 2018 UTC
>> SMART support is: Available - device has SMART capability.
>> SMART support is: Enabled
>>
>
> Ok, so it seems that not everyone is affected, thank you for the
> info.
>
> Can you do:
>
> cat /sys/class/dmi/id/bios_version /sys/class/dmi/id/bios_date
>
> And let me know the output. Also related to this have you
> updated your BIOS recently / are you in the habbit
> of tracking BIOS updates? I'm wondering if this is BIOS
> version related.


I’m going to go out on a limb and suggest that the problem might be with
power management, not with SATA per se. On a modern Intel system, an NVMe
device that hasn’t internally gone to sleep will prevent the PCIe link from
going into an ASPM sleep state, and that, in turn, will keep the whole
system from going into a deep PCn state.  I could easily believe that
there’s a bug where nasty ACPI things like brightness hotkeys go terribly
wrong in deep PC states.  I would also believe that the lack of SATA LPM
will also block deep PC states.  And I’d believe that the laptop has an
electrical problem that only affects Linux for mysterious reasons.

As an experiment, could some affected users try running ‘while true; do
true; done” or otherwise pinning a CPU at 100% and seeing if the problem
goes away?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JIWZE2WQSTN4YZAXNZ76UPNH4SJN4FXF/

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

[Andrew Lutomirski]

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.

 PackageArch Version   Repository  Size
===$
Upgrading:
 vim-common x86_64   2:8.0.1788-1.fc28 updates6.4 M
Removing:
 vim-enhanced   x86_64   2:8.0.1763-1.fc28 @updates   2.9 M

Somehow dnf's solution was to upgrade vim-enhanced and them
immediately remove it.  How does that make sense?

This was triggered by the following problem with the repo:

 Problem 1: cannot install the best update candidate for package vim-enhanced-2$
8.0.1763-1.fc28.x86_64
  - nothing provides perl(:MODULE_COMPAT_5.26.2) needed by vim-enhanced-2:8.0.1$
88-1.fc28.x86_64
 Problem 2: package vim-enhanced-2:8.0.1763-1.fc28.x86_64 requires vim-common =
2:8.0.1763-1.fc28, but none of the providers can be installed
  - cannot install both vim-common-2:8.0.1788-1.fc28.x86_64 and vim-common-2:8.$
.1763-1.fc28.x86_64
  - problem with installed package vim-enhanced-2:8.0.1763-1.fc28.x86_64
  - cannot install the best update candidate for package vim-common-2:8.0.1763-$
.fc28.x86_64
  - nothing provides perl(:MODULE_COMPAT_5.26.2) needed by vim-enhanced-2:8.0.1$
88-1.fc28.x86_64

but I don't see how it makes sense at all.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Why size of repositories metadata is too high in Fedora?

[Andrew Lutomirski]

> On Mar 2, 2018, at 6:42 AM, Matthew Miller  wrote:
>
>> On Fri, Mar 02, 2018 at 03:48:46PM +0330, Farhad Mohammadi Majd wrote:
>> I don't know, I just ran "dnf upgrade" and it took metadata in
>> mentioned size, Fedora developers should answer to these questions.
>
> A very large chunk of it is this:
> https://pagure.io/packaging-committee/issue/714
>
>

I feel like that discussion is ignoring a third option: keep file deps
built preprocess the repo metadata to turn each file dep that is
uniquely satisfied by a single package into a direct dependency on
that package.  Obviously, once the package is actually installed, rpm
would record the actual deps, but that's only for the packages that
are installed.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Testers for LCD Panel Self Refresh on laptops with Intel graphics wanted

[Andrew Lutomirski]

On Thu, Feb 1, 2018 at 11:34 AM, Hans de Goede  wrote:
>
> Hi All,
>
> For the "Improved Laptop Battery Life" feature:
> https://fedoraproject.org/wiki/Changes/ImprovedLaptopBatteryLife
>
> I'm working on for Fedora 28 I would like to also try and enable
> Panel Self Refresh on laptops with Intel graphics, some quick tests
> have shown this to save another 0.5W (when idle / nothing on the
> screen changes). This is currently off be default because it is
> known to cause issues on some devices. So I think we will probably
> need a white- or black-list. But first we need more data on this.
>
> If you can spare 10 minutes, please see my blogpost for how to test
> this and send me a mail with the info request in the blogpost:
> https://hansdegoede.livejournal.com/18653.html
>

I suspect that the results may be odd.  After falling into a rabbit
hole when I tried to do this test, I learned a few things about the
i915 driver's PSR support:

 - Intel doesn't currently have any working CI coverage for PSR.

 - There's an Intel person who seems to be actively trying to fix PSR.

 - PSR on 4.15 on newish hardware (at least Skylake) is completely broken.

 - There are other known bugs.

So I'm not sure that trying to tabulate PSR functionality based on
panel type seems like it may be the wrong approach.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: cflag ffast-math

[Andrew Lutomirski]

On Thu, Jan 25, 2018 at 2:53 PM, Sérgio Basto  wrote:

> Hi,
> Question about gcc cflag ffast-math .
> Should I enable cflag ffast-math on opencv build explicitly
> ( -DENABLE_FAST_MATH=ON ) ? and I keep disable cflag ffast-math in mlt
> build [1] ?
>
>
I have no meaningful comment on compiling with -ffast-math, but you
absolutely should not *link* with -ffast-math.  See:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522

and

https://bugzilla.redhat.com/show_bug.cgi?id=1248744

Also, if any toolchain people are listening, maybe you could consider
fixing the GCC bug?  It should be easy, since it mostly consists of option
tweaking.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

[Andrew Lutomirski]

On Wed, Jan 10, 2018 at 12:01 PM, Stephen John Smoogen <smo...@gmail.com> wrote:
>
> On 10 January 2018 at 14:46, Andrew Lutomirski <l...@mit.edu> wrote:
> >
> >
> > On Wed, Jan 10, 2018 at 11:38 AM, Stephen John Smoogen <smo...@gmail.com>
> > wrote:
> >>
> >> On 10 January 2018 at 14:23, Andrew Lutomirski <l...@mit.edu> wrote:
> >> >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi <ke...@scrye.com> wrote:
> >> >>
> >> >>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
> >> >>> Kevin Fenzi wrote:
> >> >>>> Well, if this firefox update was urgent, shouldn't it have been
> >> >>>> marked
> >> >>>> urgent?
> >> >>>
> >> >>> Urgency is always in the eye of the beholder. I as a user consider all
> >> >>> security updates "urgent", and in addition, I want ALL updates as soon
> >> >>> as
> >> >>> they passed testing no matter whether they actually are urgent.
> >> >>
> >> >> You also don't want updates-testing to even exist right?
> >> >>
> >> >>>
> >> >>>>> I really don't understand why we do this "batched" thing to begin
> >> >>>>> with.
> >> >>>>
> >> >>>> To reduce the constant flow of updates that are very minor or affect
> >> >>>> very few mixed in with the major updates that affect lots of people
> >> >>>> and
> >> >>>> are urgent.
> >> >>>
> >> >>> But the users were already able to opt to update only weekly. So why
> >> >>> force a
> >> >>> fixed schedule on them?
> >> >>
> >> >> To save all the Fedora users in the world from having to update
> >> >> metadata
> >> >> for minor changes. Since there's a hourly dnf makecache every user in
> >> >> the world pulls down new metadata ever time we update a repo.
> >> >
> >> > Could Fedora, perhaps, come up with a way to make incremental metadata
> >> > updates fast?  This shouldn't be particularly hard -- a tool like
> >> > casync or even svn should work pretty well.  Or it could be a simple
> >>
> >> This sounds a lot like the Atomic project and how it does things...
> >>
> >
> > Maybe some of Atomic's infrastructure could be used to distribute metadata
> > for regular old Fedora.
> >
>
> OK clearly I should not try to help with a single sentence email as it
> didn't help anyone. I should have asked more questions on what you
> meant by metadata and what you meant by distribution and how svn would
> have been used instead.


SVN is probably a poor model, but imagine that the various metadata
files (repodata, I think) were check in, uncompressed, to an SVN repo.
Then the client could do 'svn up' and take advantage of delta
compression.  I suspect the server load would be too high, though.

Basically, what I'm getting at is that Fedora seems to distribute
comps, prestodelta, primary, filelists, and updateinfo, and they add
up to 20MB compressed for the updates repo.  AFAICT it gets
re-downlaoded from scratch every time, even though the actual list of
changes is probably minimal from day to day.

>
> I should have also asked if you knew enough
> about how atomic did things to give an informed opinion on how that
> was similar to the request. Without that we ended up talking past each
> other.
>

I don't know too much about the details.  I suspect that, if the
.xml.gz files were, instead, one file per package, then they could be
served up from an ostree repo.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

[Andrew Lutomirski]

On Wed, Jan 10, 2018 at 11:38 AM, Stephen John Smoogen <smo...@gmail.com>
wrote:

> On 10 January 2018 at 14:23, Andrew Lutomirski <l...@mit.edu> wrote:
> >> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi <ke...@scrye.com> wrote:
> >>
> >>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
> >>> Kevin Fenzi wrote:
> >>>> Well, if this firefox update was urgent, shouldn't it have been marked
> >>>> urgent?
> >>>
> >>> Urgency is always in the eye of the beholder. I as a user consider all
> >>> security updates "urgent", and in addition, I want ALL updates as soon
> as
> >>> they passed testing no matter whether they actually are urgent.
> >>
> >> You also don't want updates-testing to even exist right?
> >>
> >>>
> >>>>> I really don't understand why we do this "batched" thing to begin
> with.
> >>>>
> >>>> To reduce the constant flow of updates that are very minor or affect
> >>>> very few mixed in with the major updates that affect lots of people
> and
> >>>> are urgent.
> >>>
> >>> But the users were already able to opt to update only weekly. So why
> force a
> >>> fixed schedule on them?
> >>
> >> To save all the Fedora users in the world from having to update metadata
> >> for minor changes. Since there's a hourly dnf makecache every user in
> >> the world pulls down new metadata ever time we update a repo.
> >
> > Could Fedora, perhaps, come up with a way to make incremental metadata
> > updates fast?  This shouldn't be particularly hard -- a tool like
> > casync or even svn should work pretty well.  Or it could be a simple
>
> This sounds a lot like the Atomic project and how it does things...
>
>
Maybe some of Atomic's infrastructure could be used to distribute metadata
for regular old Fedora.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Security updates and batched pushes

[Andrew Lutomirski]

> On Jan 9, 2018, at 9:59 AM, Kevin Fenzi  wrote:
>
>> On 01/08/2018 10:53 AM, Kevin Kofler wrote:
>> Kevin Fenzi wrote:
>>> Well, if this firefox update was urgent, shouldn't it have been marked
>>> urgent?
>>
>> Urgency is always in the eye of the beholder. I as a user consider all
>> security updates "urgent", and in addition, I want ALL updates as soon as
>> they passed testing no matter whether they actually are urgent.
>
> You also don't want updates-testing to even exist right?
>
>>
 I really don't understand why we do this "batched" thing to begin with.
>>>
>>> To reduce the constant flow of updates that are very minor or affect
>>> very few mixed in with the major updates that affect lots of people and
>>> are urgent.
>>
>> But the users were already able to opt to update only weekly. So why force a
>> fixed schedule on them?
>
> To save all the Fedora users in the world from having to update metadata
> for minor changes. Since there's a hourly dnf makecache every user in
> the world pulls down new metadata ever time we update a repo.

Could Fedora, perhaps, come up with a way to make incremental metadata
updates fast?  This shouldn't be particularly hard -- a tool like
casync or even svn should work pretty well.  Or it could be a simple
ad-hoc thing.  Have the mirrors serve up both the whole metadata blob
and a list of metadata changes.  The client could grab the list of
changes from last time, compute a bitwise-identical blob, and verify
the signature on that, deltarpm style.  (But on the decompressed data,
of course -- no need to repeat the mistakes of the past.)

It seems that all this batched stuff is a rather weak hack to work
around the extreme inefficiency of Fedora's metadata distribution
model.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Andrew Lutomirski]

On Tue, Aug 1, 2017 at 1:02 AM, Florian Weimer  wrote:
> On 07/11/2017 10:26 PM, Florian Weimer wrote:
>> I ran into this unannounced change:
>>
>>   https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
>>
>> If this is accepted, all x86 hardware on which Fedora can run will
>> support SSE2, and we should reflect that in the i686 build flags.
>
> Current GCC does not seem to provide a way to enable SSE2 while
> preserving stack alignment, but not requiring it for SSE2 access to
> stack variables.  As a result, enabling SSE2 will break tons of
> third-party software which is not compliant with the increased stack
> alignment which was introduced as a silent, breaking change to the i386
> psABI about 15 years ago.
>
> I don't think it's worth fixing GCC because i386 support is legacy only
> anyway, so I'd suggest to leave things as they are (and even scale back
> the SSE2 use within glibc).

I think it's worth filing the GCC bug report.  The GCC developers
should fix this issue.

It may still be worth scaling back SSE2 support in 32-bit glibc, though.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andrew Lutomirski]

> On Jul 20, 2017, at 5:12 PM, Kevin Kofler  wrote:
>
> Richard Hughes wrote:
>> Sure they can. If you install the KDE runtime and the GNOME runtime,
>> these are both built upon the Freedesktop runtime and share a huge
>> number of files. Any duplicate files get deduplicated on disk -- you
>> don't even download the duplicates when you update either or both of
>> them.
>
> The files are still technically duplicated, they just happen to be
> deduplicatable (and as pointed out by Hedayat Vatankhah elsewhere in this
> subthread, the duplicates will still have to be downloaded in the
> implementation that is being proposed at this time, which offers the
> runtimes as single-file OCI blobs). Sharing without duplicating would mean
> having dependencies between the runtimes, so that the KDE runtime can
> actually Require the Freedesktop runtime.

Couldn't the files all be addressed by hash or even use a tool like casync?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andrew Lutomirski]

> On Jul 14, 2017, at 12:54 PM, Florian Weimer  wrote:
> The app store model also assumes that the app store operator acts as
> some sort of gate keeper, so there has to be some policy enforcement at
> this level, too.  It is not sufficient to pass through just what the
> application developer asked for.

This is only a problem because Flatpak is currently following the IMO
rather busted old Android model. With very few, if any, exceptions, I
think a much better model would be for an application to start with
basically no permissions and to have to ask for fine-grained
permissions as needed.  Think iOS but tighter.  By default, an app
shouldn't be able to use the network, see what other applications are
installed, or get your unique advertising ID without explicit consent,
let alone access your dotfiles.

I would like to see a situation in which running random Flatpaks is as
safe or safer than visitng random webpages, at least insofar as the
*intentional* surface by which it can damage you should be as small or
smaller than that of a webpage.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andrew Lutomirski]

 On Jul 14, 2017, at 11:30 AM, Richard Hughes <hughsi...@gmail.com> wrote:
>
>> On 14 July 2017 at 19:12, Andrew Lutomirski <l...@mit.edu> wrote:
>> As above, it could be the exact same sandbox technology with the same
>> portals and everything.  The sandboxed program would just be files in
>> /usr instead of a Flatpak.
>
> How could that work? The runtime gets mounted in /usr and the app gets
> mounted in /app in a different place.
> https://media.readthedocs.org/pdf/flatpak/latest/flatpak.pdf is a good
> read.

I don't see the problem.  The runtime could be all of /use and the app
could be a symlink living in /app that points at /usr.  The latter
could be created on the fly in a tmpfs.

Or the flatpak runtime could learn to accept a special type of
manifest that just says to run /usr/bin/whatever and not worry about
/app.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andrew Lutomirski]

On Fri, Jul 14, 2017 at 9:59 AM, Debarshi Ray  wrote:
> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
>> On Mon, Jul 10, 2017 at 03:31:30PM -0400, Owen Taylor wrote:
>> >  F29: packagers (of graphical applications) must create Flatpaks of
>> >   their applications if possible. They *may* keep standard RPM
>> >   packaging.
>>
>> At least we see where this is going.
>>
>> If RPMs of the graphical application work fine now, what on earth is
>> the point of forcing packagers to make Flatpaks?  Sandboxing isn't one
>> of them - as already explained, sandboxing is orthogonal to packaging.
>
> Huh? How would you get sandboxing without Flatpaks? Unless you are
> proposing a different sandboxing technology.

As above, it could be the exact same sandbox technology with the same
portals and everything.  The sandboxed program would just be files in
/usr instead of a Flatpak.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: No i686 kernel: Can we require SSE2 for i686?

[Andrew Lutomirski]

I'll bite, sort of.  When bugs get reported through normal upstream
channels that affect parts of the kernel that I'm involved in, they
generally get fixed.  That includes i686 and even 486.  I flipped through
several of the open i686 Fedora bugs, and they look familiar and look like
issues that are now fixed.  In practice, the upstream kernel seems to work
quite well on i686, and 486 support is likely better than it's been in
years.

So I'm wondering if a decent solution would be for the Fedora kernel
maintainers to keep building i686 kernels but to explicitly not support
them.

Of course, Fedora  should strongly encourage users with 64-bit capable
hardware to run 64-bit Fedora and maybe even provide an upgrade path.
Heck, maybe the kernel packages could be jiggered up to put a 64-bit kernel
on i686 Fedora if the CPU supports it.

--Andy

On Jul 12, 2017, at 1:03 PM, Eric Griffith  wrote:

My own two cents in this whole thing, after reading this entire thread...
Matt's right.

This isn't a call to action because the release is a week away and there's
critical 32-but bugs that need fixed. This isn't a call for support because
there's specific bugs that need fixed.

This is a call to arms for a handful of people--a team-- to own 32-bit
kernels and their issues both now AND into the future. To deep dive EVERY
issue that comes in and figure out the problem, and fix it.

Hans, the reason you're not getting a list of specific bugs, is because
thats kind of the point. "What can we do to help?" isn't really a helpful
question. It implies specific issues, which misses the point.

What you, or anyone else, can do to help is step up and say "I am willing
to own i686 kernels from this moment and going into the future. I will
triage bugzilla and prioritize things, I will ask for help on specific
issues once I have identified them." And then go down that.

Unless someone steps up, the reality is i686 kernels are gonna die. They
may not OFFICIALLY die, but they'll die a slow death because no one cares,
and no one is testing outside of OpenQA. Bugs will occur, breaks will
happen, maybe they'll get reported or maybe they won't.

Personally I couldn't care less about i686 kernels or whether or not they
work. Every machine I own is 64bit capable and has 4Gb of RAM or more.

If anyone out there DOES care about these kernels, AND has the time to
donate AND has the skills necessary to support them, AND actually cares
about this enough to actually put in the time.. then they need to speak up.

Cheers!
Eric

On Jul 12, 2017, at 15:17, Samuel Sieb  wrote:

On 07/12/2017 12:12 PM, Matthew Smith wrote:

On Wed, Jul 12, 2017 at 8:03 PM, Samuel Sieb  wrote:

I guess if this change goes through I

will be looking into how to run a 64-bit kernel and 32-bit userspace.  We

also still have a few laptops that are running 32-bit Fedora, but they don't

have to and they will all be retired within a year anyway.

Why do you want to keep the 32-bit userspace?


I could be wrong, but since they only have 2GB of RAM, I think that the
32-bit userspace takes less runtime memory.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Graphical Applications as Flatpaks

[Andrew Lutomirski]

After reading this, I think there's a false dichotomy here:

On Tue, Jul 11, 2017 at 9:26 PM,   wrote:
> On Tue, Jul 11, 2017 at 7:45 PM, Kevin Kofler 
> wrote:
>>
>> There ought to be better ways to sandbox applications than to turn them
>> into
>> what is essentially a full container (i.e., almost a full VM, only minus
>> the
>> kernel), bundling all the libraries. The split into an application and a
>> runtime that Flatpak does is only a partial workaround.
>
>
> I don't think there are better ways to sandbox applications. Sandboxing is
> what has really sold me on Flatpak.

Flatpak provides two things that are very nearly orthogonal: packaging
and sandboxing.  Packaging is the system of bundles, apps, runtimes,
etc that allows you to build a Flatpak, send it to a different
machine, and run it there, even if the other machine runs a different
distro.

Sandboxing is Flatpak's system of portals, confinement, etc.

Aside from the fact that both are based on namespaces, I see no reason
at all that they need to be conflated.  It should be entirely possible
for Flatpak ro run an "app" that is actually a conventional RPM
installed on the host system using host libraries.  Flatpak would just
map all of /usr into its namespace rather than mapping a container
bundle into its namespace.  The sandbox would work exactly the same as
for any other Flatpak except that the sandboxed app would be able to
read all of /usr.  Arguably, in a model where all of /usr is visible
in the app's namespace, development and debugging might be
considerably easier.

Perhaps Fedora should consider a scheme where graphical application
RPMs are augmented with the metadata needed to run them inside Flatpak
while still packaging them the old-fashioned way with old-fashioned
RPM library dependencies and old-fashioned build tools.  This would
almost certainly entail modifications to Flatpak, but I bet they'd be
fairly minor modifications and quite possibly much less complex than
all the tooling needed to get the average graphical application RPM to
build a functional Flatpak bundle.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: power management

[Andrew Lutomirski]

On Apr 10, 2017 7:39 AM, "Richard W.M. Jones"  wrote:

On Fri, Apr 07, 2017 at 04:47:54PM -0600, Chris Murphy wrote:
> 01.org has several projects related to power management, but most
> aren't in Fedora repositories. Are any of these useful for the recent
> effort to make power management better on Fedora?

If you're packaging things, it'd be nice to have TLP in Fedora for all
of us Thinkpad users:

  http://linrunner.de/en/tlp/docs/tlp-linux-advanced-power-management.html

Actually TLP is included in Fedora already.  Unfortunately it requires
two (at least) out of tree kernel modules to really make it
functional, so the work is resolving why those aren't upstream and
what it would take to get them upstream.  These enable setting battery
thresholds, which can really prolong the life of laptop batteries.


For tp-smapi, I have a user program that can do it with no module.
Arguably a good module would be better.

acpi_call was nakked upstream and has approximately zero chance of making
it in.  The right fix is to write a real driver.

IMO the best way to handle this would be to teach the Linux battery sysfs
code to allow subdrivers to register to provide advanced functionality.
Unfortunately, I don't use a Thinkpad anymore.


I should also note that the link above has a Fedora repo, but it's
been uninstallable for me for a little while.

And yes, I know I should be doing the work ...

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~
rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: httpd illegal instruction by rebuild with rpmrc file

[Andrew Lutomirski]

On Apr 10, 2017 2:28 PM, "Dominik Kucher"  wrote:

when i rebuild the src.rpm with my .rpmrc file i became the error "illegal
instruction", when i create the rpm without the .rpmrc file it works
perfectly!
other builds (pure-ftpd, mpd, mpdscribble, samba, openssl) works with my
rpmrc file, but why it breaks httpd-* and mod_* files? maybe the problem of
my mod_ssl build?
 i use the httpd-2.4.25-3.fc25.src.rpm file

This is my .rpmrc file:

[builduser@buildsrv]: cat /home/builduser/.rpmrc
optflags: x86_64 %{__global_cflags} -m64 -march=core2 -mtune=core2



The obvious cause would be if you are not, in fact, using a core2.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora kernel crashing in virtio when running on qemu

[Andrew Lutomirski]

On Tue, Mar 21, 2017 at 3:59 PM, Adam Williamson
 wrote:
> On Tue, 2017-03-21 at 20:48 +, Richard W.M. Jones wrote:
>> On Tue, Mar 21, 2017 at 12:58:06PM -0700, Adam Williamson wrote:
>> > On Tue, 2017-03-21 at 19:40 +, Richard W.M. Jones wrote:
>> > > https://bugzilla.redhat.com/show_bug.cgi?id=1430297
>> > >
>> > > This has been going on for a few weeks with no attention.  It prevents
>> > > anyone from running libguestfs on Fedora 26.
>> > >
>> > > It's (IMHO) pretty serious for anyone using virtualization: "kernel
>> > > doesn't boot on qemu" should be a blocker for a Fedora release.
>> > >
>> > > Can anyone see what's going on?
>> >
>> > The earlier case looks like
>> > https://bugzilla.redhat.com/show_bug.cgi?id=1430043 , which was fixed
>> > in rc2. I'm not sure about the latter case, though Thorsten Leemhuis
>> > reported intermittent crash / hang during boot with rc2 as:
>> >
>> > https://bugzilla.kernel.org/show_bug.cgi?id=194911
>> >
>> > Since rc2 I've seen occasional failures which are probably the same as
>> > the ones Thorsten was seeing, but usually it works OK. I run 26-on-26
>> > VMs via virt-manager quite a lot, they certainly don't fail every time.
>>
>> Does libguestfs-test-tool work for you in F26?
>
> Hum, interesting results:
>
> If I run it as a regular user, it works.
> If I run it as root as usual, it gives me a libvirt error, some
> permission issue.
> If I run it as root with LIBGUESTFS_BACKEND=direct , it hits the same
> kernel trace you hit.

Off the top of my head, I'd guess that the failing cases are using
vhost on the host.  I've never used vhost in my life, so I have no
clue about it.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: packaging work is becoming increasingly cumbersome

[Andrew Lutomirski]

On Tue, Jan 31, 2017 at 2:26 PM, Julian Sikorski  wrote:
> While I am sure these changes are done with an aim of improving things
> in the long run, the churn caused by them is really starting to take a
> toll on my motivation. Could something be done to mitigate the
> inconveniences caused by the infrastructure upgrades?
>

From memory, there seem to have been a number of server-side changes
in Fedora's infrastructure that are deployed before the relevant
updates become stable.  Would it make sense to try to avoid making
breaking changes to the infrastructure until the mandatory updates
have been in -updates long enough to mirror out all the way?

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Anaconda LVM RAID

[Andrew Lutomirski]

On Jan 31, 2017 6:34 AM, "Chris Adams"  wrote:

Once upon a time, Jan Kurik  said:
> LVM RAID provides same functionality as MD
> RAID (it shares the same kernel code) with better flexibility and
> additional features expected in future.

How do LVM RAID volumes get tested?  There's a regular cron job for
testing MD RAID volumes, but I'm not aware of something like that for
LVM RAID.


For that matter, how do you administer it?  For MD RAID, there's mdadm.
Does LVM RAID have a fully-featured equivalent?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Increasing compatibility with rpm-ostree for host packages

[Andrew Lutomirski]

On Mon, Jan 23, 2017 at 11:09 AM, Colin Walters  wrote:
> On Mon, Jan 23, 2017, at 02:03 PM, Tom Hughes wrote:
>
>> How about you just explain here what it is you want rather than making
>> everybody go and read some bug?
>
> OK, here's a copy of the text:
>
> rpm-ostree is a new model for rpm packages on using ostree[0].  In order to 
> implement atomic upgrades without special filesystem support, it runs %post 
> scripts using rofiles-fuse[1]
>
> This means that %post scripts, whenever replacing an existing file, must do 
> create-new-then-rename, rather than open(O_TRUNC).  This is a core 
> distinction between `/usr/bin/install` and `/usr/bin/cp`.
>

I'm the owner of an affected package and, after thinking about this a
bit, I'm somewhat disinclined to change my %post script.  I would have
to make it considerably more complicated to comply with this, and
doing so would only fix my package.  I think I'd much prefer for
rofiles-fuse to become more permissive so that existing scripts keep
working, thus fixing many packages in one go.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Proposal: Rethink Fedora multilib support

[Andrew Lutomirski]

On Jan 5, 2017 9:03 AM, "Jonathan Wakely" 
wrote:.



The main
> difference would be installation/deployment. The idea would be that
> instead of
> the 32-bit and 64-bit runtimes being installed directly in parallel on the
> base
> system, they would instead be installed into effectively a chroot with its
> own
> completely 32-bit runtime.
>

Which changes how software is built, surely.

Tom's use case is where you simply invoke "gcc -m32" on the base
system and (assuming the relevant 32-bit versions of the libs are
present in /usr/lib) it Just Works.

If the 32-bit headers and libs aren't present on the base system then
you have to change how the software is built.


The Linux kernel needs gcc -m32 to work for freestanding programs.

Linux's x86 test suite likes normal glibc programs built with gcc -m32 to
work.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Debugging random suspend?

[Andrew Lutomirski]

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. A couple seconds later, sleep

If I manage to type my whole password between 2 and 3, the system will
subsequently resume unlocked.  Ouch.  The system should resume locked
*regardless of pre-suspend state*.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Status of microcode updates

[Andrew Lutomirski]

On Sat, Dec 10, 2016 at 2:23 AM, Florian Weimer  wrote:
> On 12/09/2016 11:16 PM, Peter Robinson wrote:
>>
>> On Fri, Dec 9, 2016 at 11:10 AM, Florian Weimer 
>> wrote:
>>>
>>> We would like to enable hardware-assisted lock optimizations in glibc on
>>> multiple architectures.  In general, this feature works only on
>>> production
>>> hardware with current firmware, and not on pre-production machines some
>>> vendors provide for architecture bringup.
>>
>>
>> Have you got an overview of the required instructions/generations of
>> CPU architecture needed for each different architecture by chance?
>
>
> I'm afraid not.  Even the information on ark.intel.com is not accurate
> because it lists TSX support at launch time and does not take into account
> subsequent firmware updates which disable TSX.  Based on ark.intel.com,
> Broadwell and Skylake Xeons seem to support TSX, and Haswell-EX Xeons as
> well, but some other Haswell Xeons do not.
>
> In /proc/cpuinfo, the Intel feature appears as “rtm” (even though the
> marketing name is TSX).
>
> I don't know where the POWER8 support status appears.  It could well be the
> case that all POWER8 CPUs support the form lock elision of that glibc
> supports (optionally).
>
>> From there it might be  easier to give details of where all the build
>> HW is at. In the case of build VMs (x86/aarch64/Power64) does this
>> need to be emulated by qemu/kvm or is it passed through from the host
>> CPU?
>
>
> TSX does not need hypervisor support AFAIK.  We are trying to get
> clarification from KVM folks which CPUID values can be influenced by the
> hypervisor.  We are concerned that the hypervisor makes a CPU with broken
> TSX look like one with working TSX (so that Debian-style software
> blacklisting of TSX fails).

KVM should arguably take care of this itself: mask off TSX in CPUID on
problematic CPUs.  Actually obtaining the list of problematic CPUs may
be difficult.  But maybe it's easy -- Intel often documents errata
fairly well.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: i686 [was Re: how does Fedora 24 x86_64 boot on EFI-32?]

[Andrew Lutomirski]

On Mon, Dec 5, 2016 at 4:11 PM, Matthew Miller  wrote:
> On Mon, Dec 05, 2016 at 08:51:35AM -0500, Matthew Miller wrote:
>> into it, and it's in the middle of his priorities somewhere between
>> "actual urgent work" and "other actual important work"), but
>> preliminary stats show a big drop in i686 mirror connections over the
>> last year — like, about cut in half. I'm not sure if this is a glitch
>> or representative of a real move — or whether it's because of perceived
>> or actual changes we've made, or just because people's old hardware is
>> hitting an end-of-life wall.
>
> For previous years, the percentage of hits to the mirror server (one IP
> counted per day) looks like this:
>
>   2007 - 85.3%
>   2008 - 80.6%
>   2009 - 76.9%
>   2010 - 71.5%
>   2011 - 65.4%
>   2012 - 56.2%
>   2013 - 46.0%
>   2014 - 35.7%
>   2015 - 22.1%
>
> So, roughly 5 percentage points lost the each year until 2012, and 10
> points a year after that. The average so far of 2016 is 17.9%, but
> that's a little deceptive because of the big drop I mentioned above —
> it's in the 20s at the beginning of the year, but around summer dropped
> to 15% or so and is now around 12% - so looks like the drop-10 pattern
> will hold again. We'll see if it goes to 2% in 2017, though!
>

For those who have really old systems, I've been fixing *tons* of i386
regressions affecting older machines.  Some of these regressions seem
to be several years old at least.  These machines may be so old that
Fedora *userspace* won't run on them, but if you want to keep that old
80486 working, give 4.9 or 4.10 a try :)

To the kernel maintainers: one of these bugs could (according to the
SDM) potentially affect even rather new machines and cause them to
hang in early boot.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how does Fedora 24 x86_64 boot on EFI-32?

[Andrew Lutomirski]

On Sun, Dec 4, 2016 at 11:38 AM, Chris Murphy  wrote:
> Pretty sure this predates CONFIG_EFI_MIXED, so it's predicated on
> creating 32-bit EFI GRUB *and* 32-bit OS which makes it easier to
> create dedicated media that boots properly. Easier being relative, of
> course.
>
> http://askubuntu.com/questions/392719/32-bit-uefi-boot-support/715843#715843
>
> At least on Fedora, 32-bit kernel support is about to go away,
> although I don't know if that's a done deal for Fedora 26 or 27, but
> it is imminent. Ergo I don't know if putting a huge amount of
> investment in a 32-bit Mac only spin makes a lot of sense.

mjg's post about 32-bit UEFI is here:

https://mjg59.dreamwidth.org/26734.html

and that almost certainly predates EFI_MIXED, which I think was
written my Matt Fleming and is a really amazing piece of kludgery.
But it works and I see no reason that Fedora shouldn't support it.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: how does Fedora 24 x86_64 boot on EFI-32?

[Andrew Lutomirski]

On Sun, Dec 4, 2016 at 10:56 AM, Chris Murphy  wrote:
> On Sun, Dec 4, 2016 at 11:22 AM, Jack Howarth
>  wrote:
>>While evaluating various Linux distributions for repurposing a
>> MacBook Pro 2,1 as a Linux box, I was pleasantly surprised to find
>> that not only was Fedora unique in producing a bootable disk without
>> resorting to the presence of an OS x partition with eEFind, but that
>> it was unique in being about to boot the x86_64 linux kernel from
>> EFI-32 firmware.
>
> No. There's no 32-bit UEFI bootloader stuff being built in Fedora. If
> it's booting, I suspect that the EFI compatibility support module
> (CSM-BIOS) is being triggered, and this is actually a legacy BIOS
> boot. If you get it booted, you can do 'efibootmgr -v' and post the
> results. Basically if you get some lines that look like entries, then
> it's a UEFI boot, and if you get an error then it's a BIOS boot.
>
>

Fedora does, however, configure the kernel with CONFIG_EFI_MIXED=y.
If you can get the kernel to be invoked by 32-bit UEFI, it should
work.

(I've looked at the somewhat terrifying kernel code that makes this
work, but I've never tried to use it.  I neither own nor want to own a
machine with 32-bit UEFI.  Supposedly it's possible to test under
OVMF.)

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

[Andrew Lutomirski]

On Nov 24, 2016 2:03 AM, "Carlos Garnacho"  wrote:
>
> Hi,
>
> > On Wed, Nov 23, 2016 at 5:03 PM, Carlos Garnacho  >
> > I'm objecting to whatever piece of software opens thoroughly untrusted
> > files out of ~/Downloads and parses them.  If that's not "Tracker",
> > then I apologize.
> >
> >
> > Firefox is a big piece of code that loads untrusted stuff.  It's
> > written in a memory-unsafe language, and there's a big team working on
> > fixing that.  It's not sandboxed, and there's a project to fix that.
> > And it's still a major attack vector, but at least it has a very
> > serious security team.
>
> Sounds great, do they also get the blame for gstreamer bugs? I've got
lots of fun so share ;).
>
> According to you Firefox is just as insecure, and I can tell that Firefox
uses GStreamer to open untrusted content over the internet. Why downloading
the file at all, you could be tricked into a webpage that auto-plays the
infected content, it could even be an ad unbeknownst by the site, you got
every bit as infected and Tracker wasn't involved, using the exact piece of
sofware as attack vector that we're talking nowadays.

Because Firefox doesn't allow all of the GStreamer content types.  And
Firefox has its own mp4 container parser written in Rust these days, I
think.

IOW they admit its a problem and they've made it better.

>
> And as for the projects themselves, Tracker is a fraction of Firefox in
terms of code size, and tracker-extract inside Tracker is another fraction.
That makes a whole lot difference between auditing or securing a *web
engine* and a process that essentially iterates over files. Why is Firefox
then any more credible? Must be the serious looks of their security team.

If a distro didn't provide a browser by default, no one would notice.  If a
distro didn't index media metadata in Downloads by default, I suspect most
users wouldn't even notice.

>
> >
> > The fact that flatpak integration is being planned is great.  I hope
> > that flatpak has an exceedingly strict mode for applications like
> > this.
> >
> > Tracker is just as exposed as Firefox because it (or some piece of it
> > or whatever) parses stuff in Downloads.
>
> Tracker-extract is not as exposed as Firefox, because the file needs
being in the local filesystem for starters. The web world is well known for
figuratively throwing 3rd party media content to your face, even in
otherwise trusted websites.
>

Then at *least* stop indexing Downloads by default.

My point is that the default tracker configuration is wildly insecure and
it could be improved quite easily.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

[Andrew Lutomirski]

On Wed, Nov 23, 2016 at 5:03 PM, Carlos Garnacho  wrote:
> There is nothing specific in Tracker *design* about opening files, at all. 
> Tracker is a semantic database with a focus on local access/content, period. 
> Your gripe happens to be against a certain implementation of these "miners" 
> populating this database, and you keep mistaking the part with the whole.

I'm objecting to whatever piece of software opens thoroughly untrusted
files out of ~/Downloads and parses them.  If that's not "Tracker",
then I apologize.

>
> So, again, there is no justification to consider every other Tracker 
> component just as insecure in this regard.
>
>> them with code that was never designed witg security in mind, is written in
>> memory-unsafe languages, isn't sandboxed, and apparently loads plugins.
>
> * Memory-unsafe languages: Sure, the same memory-unsafe language your kernel 
> is written in, or your pid 1, or your graphics server... Factoring out 
> per-mimetype extraction specifics, tracker-extract is actually dead simple: 
> 1) pick unprocessed file uri, 2) "extract metadata" black box, 3) send 
> metadata to the tracker-store process via dbus. Do you really think the 
> language of choice matters much here...?
>
> * not sandboxed: granted, as said flatpak integration is being planned. 
> You're welcome to join!
>
> * loads plugins: Wrong, tracker-extract uses a very restricted set of 
> modules, loaded from a very specific directory. One of them happens to use 
> gstreamer (the de-facto media library on linux, you know), which as it turns 
> out is *a lot* happier than tracker-extract at opening plugins. I tbh wonder 
> why aren't we debating about the future of gstreamer1-plugins-bad, or why 
> users of the gstreamer library can't whitelist the trusted modules to load.

Firefox is a big piece of code that loads untrusted stuff.  It's
written in a memory-unsafe language, and there's a big team working on
fixing that.  It's not sandboxed, and there's a project to fix that.
And it's still a major attack vector, but at least it has a very
serious security team.

The fact that flatpak integration is being planned is great.  I hope
that flatpak has an exceedingly strict mode for applications like
this.

Tracker is just as exposed as Firefox because it (or some piece of it
or whatever) parses stuff in Downloads.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

[Andrew Lutomirski]

On Wed, Nov 23, 2016 at 2:58 PM, Andrew Lutomirski <l...@mit.edu> wrote:
>
>>
>> >
>> > I would go even farther and argue that Fedora should not, by default,
>> > ever
>> > enable a miner that isn't running in *strict* seccomp mode.  If that
>> > means
>> > that cat pictures aren't identified as such, so be it.  And if it means
>> > that several Fedora releases go by with a less functional search, that's
>> > fine too.
>>
>> *points to the written above*, you're talking about rendering entire
>> applications useless based on... not exactly sure what.
>
> The applications that depend on tracker-extract are depending on wildly
> insecure code that exposes a huge attack surface.  This is IMO not okay.

Fixing this shouldn't even be hard.  It could be done like this:

Version A: Instead of having tracker-extract be a dbus service that
extracts directly, have it run tracker-extract once per file.  Rather
than passing in the file by name, though, pass it as an fd and run
tracker-extract in a context in which it has read-only access to /usr
and /etc and has nothing else in its namespace.

Version B: Have tracker-extract fork and open the file.  Before
reading it at all, though, it heavily sandboxes itself such that it
can't use the filesystem.  Then it extracts the file and exits.

It may be that tracker-extract the service is already forking once per
file, in which case these reduce to more or less the same thing.

And I really would argue that Fedora should turn off tracker-extract
by default until something like this gets done.  The current state of
affairs is, in my opinion, unacceptably dangerous.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

[Andrew Lutomirski]

On Nov 23, 2016 2:21 PM,  wrote:
>
> Hi,
>
> > On Nov 23, 2016 8:11 AM, "Stephen John Smoogen"  > wrote:
> >
> > Can we leave tracker enabled but disable literally every miner?  AFAIK
the
>
> That is literally, overreacting. Of all tracker processes, only
tracker-extract may be expected to open() potentially untrusted files,
tracker-miner-fs merely opens private tracker files, and all basic
filesystem data extraction is performed through the
opendir/stat/inotify_add_watch syscalls, what is exactly insecure in there?

Sorry, maybe I misunderstood what a "miner" is.  What I mean is: disable
anything that tries to parse file contents.  Presumably this means
tracker-extract.

>
> Sure, tracker-extract depends on "untrusted" 3rd party libraries, but
there is nothing insecure in tracker design to consider its miners an
inherent security risk.

Yes there is.  It opens files that may be drive-by downloads and parses
them with code that was never designed witg security in mind, is written in
memory-unsafe languages, isn't sandboxed, and apparently loads plugins.

This is every bit as bad as all the crapy wormable antivirus systems on
Windows that Google has been busy poking holes in.

>
> > mandatory uses of tracker only care about filenames and don't need
contents
> > at all.
>
> Not true, full-text search works over more than filenames.

Full-text search is not mandatory.  Nautilus works without it.

>
> >
> > I would go even farther and argue that Fedora should not, by default,
ever
> > enable a miner that isn't running in *strict* seccomp mode.  If that
means
> > that cat pictures aren't identified as such, so be it.  And if it means
> > that several Fedora releases go by with a less functional search, that's
> > fine too.
>
> *points to the written above*, you're talking about rendering entire
applications useless based on... not exactly sure what.

The applications that depend on tracker-extract are depending on wildly
insecure code that exposes a huge attack surface.  This is IMO not okay.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

[Andrew Lutomirski]

On Nov 23, 2016 10:12 AM, "Michael Catanzaro"  wrote:
>
> On Wed, 2016-11-23 at 16:36 +0100, Hans de Goede wrote:
> > I don't think that is entirely true. I've recently been trying
> > to get gnome3 to run on under-powered machines like cheap ARM
> > tablets, and I can do "dnf remove tracker" more or less just
> > fine, I loose totem due to some weird dependency chain, and I
> > think also gnome-documents which I guess is an issue for some
> > use-cases, but most of gnome will stay and work just fine.
>
> Besides those, also gnome-photos and gnome-music (which aren't
> installed by default currently, but will eventually be). And indexed
> search is really very important for nautilus.

That's indexed search by *name*, right?  I can't imagine *any* reason that
running a codec in the indexer is needed for nautilus.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

[Andrew Lutomirski]

On Nov 23, 2016 8:11 AM, "Stephen John Smoogen"  wrote:
>
> On 23 November 2016 at 09:36, Michael Catanzaro 
wrote:
> > On Wed, 2016-11-23 at 09:39 +0100, Florian Weimer wrote:
> >>
> >> What about the larger picture?  Can tracker be made optional again
> >> for
> >> the GNOME desktop?
> >>
> >> Thanks,
> >> Florian
> >
> > No, many of our core applications depend on tracker to be able to see
> > files, and others (e.g. nautilus) use tracker to make search not take
> > forever. I don't think we'll support running without tracker anytime
> > soon. If someone wants to work on splitting little-used GStreamer
> > plugins into subpackages or sandboxing tracker miners (e.g. maybe with
> > SELinux?) that would be a more practical way forward.
>
> In that case, I expect that we are going to be doing cleanups over and
> over again. Because while this time it is Gstreamer it could have been
> any one of the myriad other helpers pulled in.  The bigger problem is
> that the two major defenses of ALSR and DEP can be gotten past. That
> will have effects on any security decisions that have thought "too
> hard to do realistically so we rely on that".
>
>

Can we leave tracker enabled but disable literally every miner?  AFAIK the
mandatory uses of tracker only care about filenames and don't need contents
at all.

I would go even farther and argue that Fedora should not, by default, ever
enable a miner that isn't running in *strict* seccomp mode.  If that means
that cat pictures aren't identified as such, so be it.  And if it means
that several Fedora releases go by with a less functional search, that's
fine too.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F24 GStreamer zero day

[Andrew Lutomirski]

On Nov 23, 2016 6:37 AM, "Michael Catanzaro"  wrote:
>
> or sandboxing tracker miners (e.g. maybe with
> SELinux?) that would be a more practical way forward.

This seems like it would be a fantastic use of the infrastructure behind
xdg-app.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Andrew Lutomirski]

On Fri, Nov 11, 2016 at 8:47 AM, Chris Adams  wrote:

> Once upon a time, Stephen Gallagher  said:
> > The thread on Fedora Devel revealed some other issues which need to be
> > considered carefully. One of these is that of privacy: for example, the
> DHCP
> > client will send the machine's hostname as one of the cues to the DHCP
> server
> > for acquiring a lease. While this is fine on private networks, there's a
> valid
> > concern that this might be undesirable on a public hotspot.
>
> I manage several DHCP servers for service providers and public venues.
> While it is true that the client-provided hostname is logged, I would
> say it is of little value to someone trying to use that information (the
> number of "Jeff's iPhone" and such is very high).
>
> Also, if someone was trying to identify you from DHCP, they have your
> MAC address to tie everything together with (so they know if you have a
> Dell notebook or a Samsung tablet for example), and they can also narrow
> down OS and such by requested options or their absence (and that can
> start narrowing it down to releases as well).
>

> I think concerns about "leaking" a generated hostname are pretty
> minimal.  If someone is concerned about that, there are a number of
> other changes they'll probably be making, and they can set a non-default
> hostname in that process.
>

I thoroughly disagree.

NetworkManager already has the ability to randomize MAC addresses to keep
them from leaking.  DHCP options and such will, at most, identify your
distro and maybe some installed packages.  The fact that some
NetworkManager settings will leak the MAC address is *not* an excuse to
leak a hostname.  Privacy and security issues are never solved by saying
"well, there's already a problem, so let's add a new problem".

Right now, if you leave your hostname at the "localhost" default, randomize
your MAC, and route everything over a VPN, you're actually doing quite
well.  Let's not make it worse, please.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC (round 2): Change the default hostname for Fedora 26+

[Andrew Lutomirski]

On Fri, Nov 11, 2016 at 9:08 AM, Lennart Poettering 
wrote:

> On Fri, 11.11.16 11:12, Stephen Gallagher (sgall...@redhat.com) wrote:
>
> > The hostname may always be set manually and the result will (for the vast
> > majority of people) be unique within their environment. This means that
> if we
> > are concerned with hostname leakage being a privacy issue, we need to
> address
> > that at the leakage point, not at the hostname point.
> >
> > Also, there are cases where hostname leakage may be used specifically
> *because*
> > it may be unique, such as one of several cues to the DHCP server.
> Unfortunately,
> > we cannot know in advance whether a DHCP server is going to be on a
> trusted or
> > untrusted network (we might be able to guess from the SSID of a WiFI
> connection,
> > but those are remarkably easy to fake).
> >
> > In short, I really don't think that the hostname is the right place to
> solve
> > this problem. If transmission of individually-identifying information is
> a
> > concern, then we really have to solve it at the transmission points and
> not at
> > the source.
> >
> > Yes, an argument could be made that a user who sets her own hostname is
> > "opting-in" to that uniqueness, but I think that's setting an unrealistic
> > expectation on all of our users that they fully understand the
> consequences of
> > that action.
>
> I still believe we should stick to a generic hostname by default,
> (though I'd rather use "localhost" than "localhost.localdomain" in
> order to drop the redhatism that "localdomain" is), and make the IPA
> client-side enrollment code automatically update to a more "unique"
> hostname if the hostname is found to be unset or be "localhost".
>
> I am also pretty sure that DHCP clients should suppress sending local
> hostname information if the local hostname is unset or "localhost".
>
> > * I like Zbigniew and Lennart's thoughts on how to generate the "random"
> suffix.
> > the implementation I'd likely use is to take the first eight characters
> of an
> > md5 (or SHA) hash of /etc/machine-id and use those. That should make it
> both
> > repeatable and unique.
>
> Please do not use MD5 anymore. And please calculate your ID as
>
>SHA(x || k)
>
> x refers to the machine id, "||" refers to concatenation and "k"
> refers to some app-specific key (which is OK to be publically
> known). It's important to concatenate the app-specific key, so that it
> is not possible to map the machine IDs used by one app to the machine
> IDs used by another..
>

/me dons crypto hat.

SHA(x || k) has three problems, one of which is bad enough to be an
absolute showstopper.

1. Specify *which* SHA.  SHA-1 should not be used for new applications.

2. Concatenation without some additional property preventing collisions of
the hashed data is problematic.  In particular, if you shorten x by a byte
and prepend the same byte to k, you get the same output.  This is probably
irrelevant for this particular use case, but it's still a sign that the
construction is bad.

3.  The SHA hashes, like all Merkle-Damgård hashes, is subject to
length-extension attacks.  In particular, if x is a multiple (or slightly
above a multiple) of the block length, then anyone who learns SHA(x) can
efficiently derive SHA(x || k).  This basically removes all security from
this scheme.

HMAC(k, x) would be much better.

But I think this protocol is generally more fragile then needed.  How about
generating a per-app-installation random value and HMAC-ing *that* with the
machine id?

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Andrew Lutomirski]

On Tue, Nov 8, 2016 at 3:28 PM, Neal Gompa <ngomp...@gmail.com> wrote:

> On Tue, Nov 8, 2016 at 6:25 PM, Andrew Lutomirski <l...@mit.edu> wrote:
> > On Tue, Nov 8, 2016 at 3:19 PM, Neal Gompa <ngomp...@gmail.com> wrote:
> >> On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
> >> <zbys...@in.waw.pl> wrote:
> >>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
> >>>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
> >>>> > SUSE generates a random name of the format linux-XX (I'm not
> sure how many
> >>>> > My proposal is that we should consider changing the default
> hostname for Fedora
> >>>> > 26 to be either FED-XXX or FEDORA-. The former
> allows for a
> >>>>
> >>>> How about non-yelly Fedora-XXX? Since SUSE apparently does
> >>>> lower case, that should be fine, right?
> >>>
> >>> Bastian Nocera also filed https://bugzilla.redhat.com/
> show_bug.cgi?id=1392925,
> >>> where he proposes "fedora" as the hostname. I think "fedora" is better
> than
> >>> "localhost", and a non-constant hostname would be even better.
> >>> For interactive installs (like with anaconda) it would be great if we
> could
> >>> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}"
> seems
> >>> like a good option (*). It would give "branding", and solve the
> freeipa issues.
> >>> It would also be a good default for the interactive case, so that
> people can
> >>> "click through" without having to pick anything.
> >>>
> >>> (*) The suffix could include dashes for more possibilities, but they
> should
> >>> not be adjacent or at the end.
> >>
> >> I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself. However,
> >> I'm concerned that people don't realize that we can, in fact, set the
> >> hostname during installation. People usually don't because Anaconda
> >> doesn't currently make that mandatory or otherwise note that it's
> >> possible during the initial panel of spokes (hint: it's the networking
> >> spoke), and so the default of "localhost" continues on without anyone
> >> being the wiser.
> >>
> >>
> >
> > If the hostname is non-constant, can we also arrange that, by default,
> > this hostname is never sent over the network?  In particular, I think
> > that DHCP requests should *not* include this hostname.  We're already
> > starting to randomize MAC addresses -- there's no reason to give a
> > persistent per-installation identifier to every network.
>
> The idea is that the hostname is randomly generated at install time.
> It definitely is constant. And speaking from experience, not including
> the hostname in DHCP requests breaks quite a few user expectations
> (especially the ability to identify the computer by name).
>
>
When I go to a random coffee shop and connect to wifi, I have a very strong
user expectation that the coffee shop *not* be able to identify me by
name.  It's even somewhat dubious to advertise to the coffee shop that I'm
using Fedora.

If this means that NetworkManager needs to generate a per-network random
client ID, so be it.  IMO a per-installation value absolutely should not be
sent to a network that is not explicitly (on an opt-in basis) configured as
trusted.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: RFC: Change the default hostname for Fedora 26+

[Andrew Lutomirski]

On Tue, Nov 8, 2016 at 3:19 PM, Neal Gompa  wrote:
> On Tue, Nov 8, 2016 at 6:14 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> On Tue, Nov 08, 2016 at 05:25:36PM -0500, Matthew Miller wrote:
>>> On Tue, Nov 08, 2016 at 04:49:42PM -0500, Stephen Gallagher wrote:
>>> > SUSE generates a random name of the format linux-XX (I'm not sure how 
>>> > many
>>> > My proposal is that we should consider changing the default hostname for 
>>> > Fedora
>>> > 26 to be either FED-XXX or FEDORA-. The former allows for 
>>> > a
>>>
>>> How about non-yelly Fedora-XXX? Since SUSE apparently does
>>> lower case, that should be fine, right?
>>
>> Bastian Nocera also filed 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1392925,
>> where he proposes "fedora" as the hostname. I think "fedora" is better than
>> "localhost", and a non-constant hostname would be even better.
>> For interactive installs (like with anaconda) it would be great if we could
>> ask for the hostname. For non-interactive ones, "Fedora-[0-9a-z-]{8}" seems
>> like a good option (*). It would give "branding", and solve the freeipa 
>> issues.
>> It would also be a good default for the interactive case, so that people can
>> "click through" without having to pick anything.
>>
>> (*) The suffix could include dashes for more possibilities, but they should
>> not be adjacent or at the end.
>
> I'm in favor of defaulting to "Fedora-[0-9a-z-]{8}" myself. However,
> I'm concerned that people don't realize that we can, in fact, set the
> hostname during installation. People usually don't because Anaconda
> doesn't currently make that mandatory or otherwise note that it's
> possible during the initial panel of spokes (hint: it's the networking
> spoke), and so the default of "localhost" continues on without anyone
> being the wiser.
>
>

If the hostname is non-constant, can we also arrange that, by default,
this hostname is never sent over the network?  In particular, I think
that DHCP requests should *not* include this hostname.  We're already
starting to randomize MAC addresses -- there's no reason to give a
persistent per-installation identifier to every network.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: DNF and PackageKit background data usage

[Andrew Lutomirski]

On Sat, Oct 29, 2016 at 5:26 PM, Adam Williamson
 wrote:
> Hi folks!
>
> I kinda hate kicking off discussions like this without having a solid
> solution to propose or being able to promise to work on one, but this
> really seems important. Unfortunately I can't claim I'm gonna have time
> to do any concrete work on it, though I'd really *like* to. But I
> thought it would be worthwhile to kick around still; perhaps someone
> else will be inspired.
>
> I just read Hedayat's review of Fedora 25 Beta:
> https://hedayatvk.wordpress.com/2016/10/30/fedora-25-beta
> and this really jumped out at me:
>
> "And, if you care about your internet usage, make sure that you disable
> both dnf makecache timer, and stop PackageKit from downloading updates
> automatically. I don’t allow a new Fedora installation to access
> internet before doing these, as it might just eat a considerable amount
> of data."
>
> There's two things I think are somewhat unfortunate here:
>

I'll add:

3) dnf and PackageKit still seem to *separately* download metadata.
Could they be made to share their metadata cache and download only one
copy?  Bonus points if they could share their cache of downloaded rpm
files, too.

4) Why is the metadata so big in the first place?  As far as I can
tell, it's a small number (3?) of xml files that don't change all that
fast.

As a simple but rather silly solution, imagine if the repodata XML
files were actually in a git repository and the local machine
maintained a clone of the git repo.  Then it would download deltas and
would probably update very quickly indeed.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Pondering security update time frames

[Andrew Lutomirski]

On Tue, Oct 25, 2016 at 6:03 PM, Adam Williamson
<adamw...@fedoraproject.org> wrote:
> On Tue, 2016-10-25 at 17:59 -0700, Andrew Lutomirski wrote:
>> 2. There doesn't appear to be a working process to get updates out
>> quickly.  As a current and pressing example, there is no build for
>> Firefox 49.0.2.
>
> There isn't really a single 'security update process', no. Releasing
> security updates is a package maintainer responsibility. I've seen
> various people pontificating in various different places about why
> there's no Firefox 49.0.2 build yet, but no-one seems to have taken the
> rather obvious step of *asking the package maintainer*, or at least no-
> one's done so and then posted the result rather than guessing about it.

Fair enough.

FWIW, I think that #1 and #3 are more severe than #2 in the sense that
#2 is sporadic and there are various mechanisms that mostly work to
notify maintainers about updates, whereas #1 and #3 are problematic
even when the maintainer responds instantaneously.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Pondering security update time frames

[Andrew Lutomirski]

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.  For reasons that
I'm sure make a lot of internal sense, updates seem to get stuck
behind broken composes and such all the time.  Can this be made
better?

IMO it should be possible for a security update to be checked,
incrementally, for sanity with respect to the rest of the package
repository, and then pushed out, without needing to do whatever
expensive work a compose does.  If some other update breaks the
compose, I don't think this should cause security updates to get
stuck.

2. There doesn't appear to be a working process to get updates out
quickly.  As a current and pressing example, there is no build for
Firefox 49.0.2.

3. AFAIK Fedora has no means by which it can participate in embargoed
updates.  For this to work, I think there ought to be private git
branches, a way to get Koji to make a private build from a private git
branch, and a way to get private karma on a private update.  Then,
when an embargo is lifted, the packager could merge the private branch
in, the various infrastructure bits could notice that the very same
git commit is now public and permit all of the private builds,
updates, and karma to become public and allow an immediate push to
updates.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F25 workstation, and (almost) hidpi displays

[Andrew Lutomirski]

On Tue, Oct 25, 2016 at 9:33 AM, Adam Williamson
 wrote:
> On Tue, 2016-10-25 at 09:30 -0700, Adam Williamson wrote:
>> On Tue, 2016-10-25 at 05:16 -0400, Bastien Nocera wrote:
>> >
>> > - Original Message -
>> > > Adam Williamson wrote:
>> > > > If you use Fedora (Workstation, at least, and I think maybe KDE too) on
>> > > > a 3200x1800 13" screen then hidpi mode will kick in, and everything
>> > > > will be sized as if you were using a 1600x900 13" screen, which is a
>> > > > pretty common setup.
>> > >
>> > > Yes, Plasma 5 definitely handles that as a hidpi display.
>> > >
>> > > But KDE is actually much smarter and can handle any DPI, though you will
>> > > likely have to configure it manually, because as you explained, the
>> > > developers of the commonly used X drivers decided to be jerks and
>> > > deliberately report a bogus geometry.
>> >
>> > [Citation really needed]
>>
>> Well, Kevin's framing of this is clearly...opionated...:) but my blog
>> post gave the citation.
>>
>> https://www.happyassassin.net/2015/07/09/of-dpis-desktops-and-toolkits/
>> https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/modes/xf86RandR12.c#n787
>>
>> as my post explained:
>
> Oh, since I'm referring to an old post I should note one thing: after I
> wrote that post (and partly because of it), GTK+'s behaviour was
> changed to just use a hardcoded default of 96dpi, like GNOME.
> Everywhere the post refers to GTK+ doing the same DPI calculation as
> KDE/Qt, that's no longer true. It doesn't do that any more.

All of this makes me wonder: should the system perhaps attempt to
estimate the number of pixels per visual inch or perhaps per degree at
expected viewing position?  This shouldn't be *that* hard -- there
would be a little table of estimated viewing distances for laptops,
desktops, and tablets, and the system could extrapolate from there.
(Projectors are probably a lost cause and perhaps it should be purely
a function of resolution.)

At the very least, it would be rather nice to have a real (not
gnome-tweak-tool or dconf) interface for scaling the UI.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: grub, grubby, btrfs, was: PSA: Do not run 'dnf update' inside GNOME, KDE ...

[Andrew Lutomirski]

On Fri, Oct 7, 2016 at 4:55 PM, Josh Boyer  wrote:
> On Fri, Oct 7, 2016 at 5:14 PM, Chris Murphy  wrote:
>> Changed this subject to match the other one I changed, so if I'm doing
>> it wrong at least I'm consistent!
>>
>> On Fri, Oct 7, 2016 at 9:22 AM, Kevin Fenzi  wrote:
>>> So, I think we would need to get buyin to get our changes into the spec
>>> and get everyone to agree on it before we would want to move to it.
>>
>> The original spec is unworkable. And attempts to expand the upstream
>> spec for real world use cases needed in Fedora haven't gone anywhere.
>> It exchanges reduced complexity in the bootloader, by increasing it in
>> the installer and increasing wasted space on the drive. I'd try to
>> help make it salvageable but I think it's pointless. Make a Fedora
>> specific version and if people like it they can adopt it.
>
> Which, in effect, could just as well be writing a "specification" for grubby.

I disagree.

The bootloader spec, update-grub, and pretty much everything except
grubby are stateless in the sense that the list of installed kernels
and other things is generated freshly each time it updates.  (The
bootloader spec does this at every boot, and update-grub does it
whenever it's run.)  These solutions don't try to let users customize
the result after the fact.  Instead, any customization is written to a
file intended for the specific purpose of customizing the boot
process, and that file is never written by automatic tools.
Bootloader spec parsing, update-grub, etc are all idempotent, which is
a *really* nice property.

Grubby attempts to parse a configuration file and apply a change for a
single kernel addition or removal to it without losing other
customizations.  This is a much harder problem to solve well.  It's
also not idempotent.  Unsurprisingly (to me, anyway), it doesn't seem
to work all that well and it's a PITA to maintain.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Andrew Lutomirski]

On Fri, Oct 7, 2016 at 2:32 PM, Chris Murphy  wrote:
> Modifying the image at all breaks the existing media verification
> option in the boot menu, and we know people get bad writes using bad
> or flaky media

This part, at least, should be relatively straightforward to get
around.  The allocation of a persistence partition literally just
create a new partition, so if the media verification could learn to
verify the partition (bitwise) instead of the whole device, it would
work fine.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Andrew Lutomirski]

On Oct 7, 2016 1:29 PM, "Frank Ch. Eigler"  wrote:
>
>
> >> > [...]  I always run dnf manually from the
> >> > command line, in a VT logged in as root.  And I can run X while doing
> >> > this and I've never had a dnf update issue.
>
> To the extent that the problem is that dnf gets interrupted when its
> xterm dies, can that be worked around by dnf SIG_IGN'ing SIGHUP /
> SIGPIPE?  Users could still deliberately interrupt it with SIGINT, but a
> terminal closure could in theory let it finish unmolested.
>

Python is weird^Wspecial.  See the bug I opened.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 proposal: Make Fedora Media Writer the officially supported USB install media creator

[Andrew Lutomirski]

On Oct 7, 2016 12:39 PM, "Adam Williamson" 
wrote:
>
> On Mon, 2016-10-03 at 20:03 +, John Florian wrote:
> > On Mon, 2016-10-03 at 12:07 -0700, Adam Williamson wrote:
> > If we do not 'support' livecd-iso-to-disk any more, we no longer
> > support:
> >
> > 1) persistent storage (via overlays)
> > 2) non-destructive write
> >
> >
> > I've known for quite some time that livecd-tools was/is to be
> > replaced with livemedia-creator, but only now did I realize that lm-c
> > won't have persistent storage -- I simply have never had the time to
> > explore it.  I'm extremely dependent on the persistent storage as my
> > whole day job revolves around making hundreds of little mostly-
> > stateless appliances for data collection purposes and has so since
> > F13 or so.  These have been built with livecd-iso-to-disk and lots of
> > glue via specialized kickstarts and other custom packages.  These
> > appliances leverage a stateless OS very robustness, but do expect
> > some persistent storage for their management.  So the above certainly
> > caught my attention.
>
> There's a slight misconception in the above.
>
> livemedia-creator *creates the image files themselves*. We're not
> talking about that in this thread. We're talking about the tools for
> taking an image that's been created - whether by livecd-creator or
> livemedia-creator or anything else - and writing them to a USB stick.
>
> The 'persistence' feature requires support both in the image itself and
> in the tool used to write it. I believe livemedia-creator-produced
> images are set up to support persistence, just like livecd-creator-
> produced images were.
>
> The issue here is that we are discussing what tools for *writing the
> image to a USB stick* should be 'supported' / 'recommended' / whatever,
> and we'd kinda like to drop livecd-iso-to-disk from that group, but it
> is currently the only one of the 'write image to stick' tools which
> supports persistence.

At the risk of muddying the waters a bit: now that OverlayFS is here, I
think that even a dd-copied image should be able to support persistence.
The image could notice that it's dd-copied (by checking GPT GUIDs or layout
or whatever), see that there's extra space at the end, and allocate it.

This could reduce the testing explosion a bit if all of the supported image
writing tools ended up being equivalent to dd.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Andrew Lutomirski]

On Tue, Oct 4, 2016 at 10:37 AM, Chris Murphy <li...@colorremedies.com> wrote:
> On Tue, Oct 4, 2016 at 11:26 AM, Andrew Lutomirski <l...@mit.edu> wrote:
>> On Tue, Oct 4, 2016 at 10:05 AM, Kevin Fenzi <ke...@scrye.com> wrote:
>>> On Tue, 4 Oct 2016 09:51:16 -0700
>>> Andrew Lutomirski <l...@mit.edu> wrote:
>>>
>>>> By that standard, why do we support dnf at all?
>>>>
>>>> $ sudo dnf upgrade
>>>> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot
>>>> when asked.
>>>>
>>>> I, for one, *like* not rebooting, and I'm perfectly capable of
>>>> rebooting manually if stuff breaks.  As far as I know, Fedora
>>>> considers plain ol' dnf to be supported.
>>>
>>> Well, the problem there, what do you mean by 'support'?
>>>
>>> In this case lots of people use dnf for updates, so IMHO it would be
>>> "we will try and keep this working, and fix anything we can, but do
>>> understand that there's a low level problem here that something could
>>> mess up updates in progress, if you want to be more sure of not hitting
>>> problems, use the offline updates in your graphical desktop"
>>>>
>>>> For server use, I'm not convinced that the offline update mechanism is
>>>> supported (at the very least, I have no idea how to trigger it), and
>>>> servers have the same issue.
>>>
>>> Much less so. In the server case you have usually ssh, bash and dnf, in
>>> the desktop case you have X, possibly wayland, tons of graphics
>>> libraries, the terminal application you are using and all it's
>>> libraries, and a shell and dnf. There's just a lot more there to
>>> possibly crash.
>>
>> My point is that a lot of this exposure could be avoided.  Sure,
>> there's a decent chance that updating packages will crash running
>> programs.  But, unless one of those programs is dnf, rpm, or systemd,
>> that shouldn't be an excuse to blow up the whole upgrade.
>
>
> I think it's avoided by propagating the point adamw started the thread for.
>
> User: Doctor, it hurts when I do this!
> DocAdamW: So then don't do that!
>
> Do users need an INFO message when running 'dnf update' to kill off
> the myth that without a warning it's expected to be reliable? Maybe.
>

I've pondered this a bit, and I think I disagree with you.
A more apt analogy would be:

User: Doctor, it hurts when I walk.
Doctor: So don't walk.

The System Administrator's Guide tells people to use dnf [1].  I agree
that, in the long run, online updates of the system are probably the
wrong solution.  But the long run isn't here, and we could do a whole
lot better than we do right now with a straightforward change.

>
>
> > I've had
> > Firefox blow up many times due to concurrent dnf, but this doesn't
> > hose my system.  Having gnome-terminal or X or Wayland die shouldn't
> > be any more dangerous.
>
> I don't understand how you arrive at this conclusion. dnf is sitting
> on the top of a house of cards when it's running in Terminal. If
> anything below it dies, dnf dies and by extension so is rpm. Could dnf
> be put into it's own session or scope (whatever it's called), and
> would that prevent it from dying if the whole GUI died?

Yes.  dnf would prepare the transaction, solve dependencies, etc, and
then kick off a service to do the actual work.  The service would pipe
the progress state and such back to the client.

> Even if true,
> how does the user know to wait XX minutes before hitting the reset
> button? I think it's a rabbit hole, just stop touching the owie.
>

In my entire experience administering Linux machines, I have *never*
had serious package problems due to a transaction failing for any
reason *other* than loss of the session that the package manager is
running in.  So I really do think it's a 90% solution to the problem
that doesn't even require changing anyone's workflow.

So I filed the RFE.  I think this should also be a prerequisite for
the KillUserProcesses change.

https://bugzilla.redhat.com/show_bug.cgi?id=1382224

[1] 
https://docs.fedoraproject.org/en-US/Fedora/24/html/System_Administrators_Guide/sec-Installing.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Andrew Lutomirski]

On Tue, Oct 4, 2016 at 10:05 AM, Kevin Fenzi <ke...@scrye.com> wrote:
> On Tue, 4 Oct 2016 09:51:16 -0700
> Andrew Lutomirski <l...@mit.edu> wrote:
>
>> By that standard, why do we support dnf at all?
>>
>> $ sudo dnf upgrade
>> Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot
>> when asked.
>>
>> I, for one, *like* not rebooting, and I'm perfectly capable of
>> rebooting manually if stuff breaks.  As far as I know, Fedora
>> considers plain ol' dnf to be supported.
>
> Well, the problem there, what do you mean by 'support'?
>
> In this case lots of people use dnf for updates, so IMHO it would be
> "we will try and keep this working, and fix anything we can, but do
> understand that there's a low level problem here that something could
> mess up updates in progress, if you want to be more sure of not hitting
> problems, use the offline updates in your graphical desktop"
>>
>> For server use, I'm not convinced that the offline update mechanism is
>> supported (at the very least, I have no idea how to trigger it), and
>> servers have the same issue.
>
> Much less so. In the server case you have usually ssh, bash and dnf, in
> the desktop case you have X, possibly wayland, tons of graphics
> libraries, the terminal application you are using and all it's
> libraries, and a shell and dnf. There's just a lot more there to
> possibly crash.

My point is that a lot of this exposure could be avoided.  Sure,
there's a decent chance that updating packages will crash running
programs.  But, unless one of those programs is dnf, rpm, or systemd,
that shouldn't be an excuse to blow up the whole upgrade.  I've had
Firefox blow up many times due to concurrent dnf, but this doesn't
hose my system.  Having gnome-terminal or X or Wayland die shouldn't
be any more dangerous.

>
> kevin
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>


So, yes, offline updates or ostree-style updates are better in many
respects, but as long as we provide plain dnf, I think it would be
worth the small amount of effort to make dnf robust against the
terminal dying.

--Andy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Andrew Lutomirski]

On Tue, Oct 4, 2016 at 9:09 AM, Stephen Gallagher <sgall...@redhat.com> wrote:
>
> On 10/04/2016 12:06 PM, Andrew Lutomirski wrote:
> >
> > On Oct 4, 2016 8:52 AM, "Adam Williamson" <adamw...@fedoraproject.org
> > <mailto:adamw...@fedoraproject.org>> wrote:
> >>
> >> Recently several reports of people getting 'duplicated packages' and
> >> 'kernel updates not working' have come through to us in QA from Fedora
> >> 24 users. I managed to get one reporter to explain more specifically
> >> what happened, and it sounds a lot like what's happening is that
> >> something in the 'dnf update' process can cause a GNOME or X crash,
> >> possibly depending on hardware or package set installed. When that
> >> happens, the update process is killed and does not complete cleanly,
> >> which is why you get 'duplicated packages' and other odd results.
> >
> > How hard would it be to make dnf do the rpm transaction inside a proper
> > system-level service (transient or otherwise)?  This would greatly increase
> > robustness against desktop crashes, ssh connection loss, KillUserProcs, and
> > other damaging goofs.
>
> That seems like a waste of effort, considering we have the offline updates
> process which just boots into a special, minimalist environment with almost
> nothing but the updater running.
>
>

By that standard, why do we support dnf at all?

$ sudo dnf upgrade
Error: dnf upgrade is dangerous.  Use PackageKit instead and reboot when asked.

I, for one, *like* not rebooting, and I'm perfectly capable of
rebooting manually if stuff breaks.  As far as I know, Fedora
considers plain ol' dnf to be supported.

For server use, I'm not convinced that the offline update mechanism is
supported (at the very least, I have no idea how to trigger it), and
servers have the same issue.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: PSA: Do not run 'dnf update' inside GNOME, KDE or any other graphical desktop on Fedora 24

[Andrew Lutomirski]

On Oct 4, 2016 8:52 AM, "Adam Williamson" 
wrote:
>
> Recently several reports of people getting 'duplicated packages' and
> 'kernel updates not working' have come through to us in QA from Fedora
> 24 users. I managed to get one reporter to explain more specifically
> what happened, and it sounds a lot like what's happening is that
> something in the 'dnf update' process can cause a GNOME or X crash,
> possibly depending on hardware or package set installed. When that
> happens, the update process is killed and does not complete cleanly,
> which is why you get 'duplicated packages' and other odd results.

How hard would it be to make dnf do the rpm transaction inside a proper
system-level service (transient or otherwise)?  This would greatly increase
robustness against desktop crashes, ssh connection loss, KillUserProcs, and
other damaging goofs.

I once hosed a RHEL5 system when an ssh terminal running yum died.  Sigh.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: t460s fedora 24 - display freeze

[Andrew Lutomirski]

On Sep 20, 2016 7:31 AM, "Dusty Mabe"  wrote:
>
>
> Several times over the past month my t460s has just blank screens
> when I come back to it after some time. I don't know if the thing
> froze up completely or if it is just the display not working. I lock
> my screens (laptop + 2 external monitors) and then leave for an hour
> or so. When I come back no attempt at input will get the lockscreen
> to appear. I have to power down and then back up.
>
> After boot I look at the journal and I always tend to see some of
> these:
>
> [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO
underrun

Sadly, i915 has had issues on and off with Skylake.

> [drm:intel_pipe_update_end [i915]] *ERROR* Atomic update failure on pipe
C (start=167156 end=167157) time 146 us, min 1073, max 1079, scanline start
1072, end 1082

This smells like a bug that was fixed in the 4.8 series a bit late IIRC.
Search for i915 SAGV.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Testing request: AMD chipset kernel issue

[Andrew Lutomirski]

On Aug 20, 2016 4:50 PM, "Andrew Lutomirski" <l...@mit.edu> wrote:
>

>
> How about ordinary earlyprintk to serial?
>
> Try booting with nokaslr, though.  There was a bug, now fixed upstream (I
think) that broke AMD early microcode if kaslr was used.  You would likely
trigger it only on systems for which an early update exists.

The patch is
http://git.kernel.org/tip/88b2f634028f1f38dcc3d412e10ff1f224976daa

>
> --Andy
>
> >
> > --
> > Chris Murphy
> > --
> > devel mailing list
> > devel@lists.fedoraproject.org
> >
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Testing request: AMD chipset kernel issue

[Andrew Lutomirski]

On Aug 20, 2016 4:38 PM, "Chris Murphy"  wrote:
>
> On Fri, Aug 19, 2016 at 11:16 PM, Luya Tshimbalanga
>  wrote:
> > On 19/08/16 08:11 PM, Adam Williamson wrote:
> >> On Fri, 2016-08-19 at 18:53 -0700, Luya Tshimbalanga wrote:
> >>> On 19/08/16 12:58 AM, Kamil Paral wrote:
> > Possibly as I boot the livemedia from the plain old burned DVD for
> > testing purpose. Perhaps doing the verification
> > check detect the problem.
>  Just to make sure - have you just tried to boot the LiveCD, or have
you installed it and booted the installed system?
> 
> >>> I just booted the LiveCD which went to Gnome Session aside SELinux
> >>> permission issue.
> >> Kamil found the bug only occurs when booting the installed system, not
> >> just booting the live CD. So you have to run an install to fully test
> >> this. I did write that in the initial mail :)
> >>
> > I realize that.  I was able to fully reproduce the bug by installing
> > Fedora 25 on Gnome Boxes.
> > It also affect rawhide version as well. It seems this bug impacted non
> > AMD system too.
> >
> > Broker URL: qemu+unix:///session
> > Domain: boxes-unknown-3
> > UUID: de8fb221-fc8a-456f-ab7d-6234b931d2c2
> > Persistent: yes
> > Cpu time: 19789000
> > Memory: 4173824 KiB
> > Max memory: 15346692 KiB
> > CPUs: 4
> > State: GVIR_DOMAIN_STATE_RUNNING
> > URI: (null)
> > Auto clipboard sync: yes
> > Spice-gtk version 0.32
> > Mouse mode: server
> > Agent: disconnected
>
>
> OK that's good news maybe, easy to connect with virsh console and
> capture what's going on. I was gonna suggest netconsole for baremetal
> case.

How about ordinary earlyprintk to serial?

Try booting with nokaslr, though.  There was a bug, now fixed upstream (I
think) that broke AMD early microcode if kaslr was used.  You would likely
trigger it only on systems for which an early update exists.

--Andy

>
> --
> Chris Murphy
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: User instances of systemd and SELinux

[Andrew Lutomirski]

On Mon, Aug 15, 2016 at 12:59 PM, Daniel J Walsh <dwa...@redhat.com> wrote:
>
>
> On 08/10/2016 03:42 PM, Andrew Lutomirski wrote:
>> On Wed, Aug 10, 2016 at 12:26 PM, Zbigniew Jędrzejewski-Szmek
>> <zbys...@in.waw.pl> wrote:
>>> On Tue, Aug 09, 2016 at 01:32:10PM -0400, Daniel J Walsh wrote:
>>>>
>>>> On 08/09/2016 10:24 AM, Michal Sekletar wrote:
>>>>> Hi all,
>>>>>
>>>>> Most of you are probably aware that systemd except running as PID 1
>>>>> also runs inside user sessions. This allow users to define their own
>>>>> "user services" and start up various scripts and background processes
>>>>> right after logging in.
>>>>>
>>>>> In default targeted policy PID 1 runs with init_t SELinux label and
>>>>> --user instances of systemd are not confined by SELinux, i.e. running
>>>>> with unconfined_t.
>>>>>
>>>>> During Flock I got asked whether we can change that and run systemd
>>>>> --user instances in some confined domain. Fixing this on systemd side
>>>>> should be trivial, i.e. we would have to add SELinuxContext= option
>>>>> with appropriate value to /usr/lib/systemd/system/user@.service (unit
>>>>> file used for spawning user instances of systemd).
>>>>>
>>>>> I am writing this email with a hope that we can discuss if above
>>>>> proposal even makes sense (what are possible gains from system
>>>>> security perspective) and if yes what is appropriate SELinux label to
>>>>> use (I guess we would need new one and define policy for it).
>>>> Yes we should allow for systemd to specify a label, but the label needs
>>>> to be transitioned from the user domain.
>>>>
>>>> For example if I login as unconfined_t and want to run a service as
>>>> httpd_t, then I need to be able to transition from
>>>> unconfined_t to httpd_t.  As long as systemd-user is running as the user
>>>> domain, then SElinux will control this.
>>> That doesn't seem useful ;) Why would a user by able run anything as 
>>> httpd_t?
>>> The way I understand Michal's question is: in what ways specifying a
>>> context for systemd --user that is different than current 
>>> unconfined_u:unconfined_r:unconfined_t
>>> would be actually useful? What general rules for transitions could be 
>>> provided?
> That was just an example.  The idea would be to allow  a user to build a
> service that he wants to run at boot time or login time from
> his homedir. But wants to lock it down and at least isolate it from his
> homedir.  Running it with a container type for example.  We are
> working on non-root service containers.

I thing doing this is very valuable, but it doesn't need selinux or
any other form of MAC, and what I'm saying is that I'd like to see
this type of isolation be implemented in a way that doesn't require
selinux or any other LSM.

>> My intuition is that, especially for non-root processes, using the
>> various sandboxing features available without MAC or any privileged
>> configuration (ProtectXYZ, namespaces, seccomp, etc) is already a good
>> deal easier to work with, more flexible, and less needing of
>> centralized policy than SELinux.  Maybe Fedora should focus on that
>> type of isolation for systemd user instances rather than trying to
>> make SELinux work for them.
> I don't see seccomp as being a good deal easier, but the point being we
> want to take
> advantage of all isolation tecnigues available in Linux.  Dropping Caps,
> Read Only file system
> labeled file isolation, dropped syscalls ...

Everything you've mentioned with the sole exception of labeled files
is something that naturally offers its full power and configurability
directly to the process doing to isolation without needing any
systemwide configuration.  So a user systemd can isolate a user daemon
by itself without needing to ship privileged policy or to get a
privileged process to label files on the user's behalf.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: User instances of systemd and SELinux

[Andrew Lutomirski]

On Wed, Aug 10, 2016 at 12:26 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Tue, Aug 09, 2016 at 01:32:10PM -0400, Daniel J Walsh wrote:
>>
>>
>> On 08/09/2016 10:24 AM, Michal Sekletar wrote:
>> > Hi all,
>> >
>> > Most of you are probably aware that systemd except running as PID 1
>> > also runs inside user sessions. This allow users to define their own
>> > "user services" and start up various scripts and background processes
>> > right after logging in.
>> >
>> > In default targeted policy PID 1 runs with init_t SELinux label and
>> > --user instances of systemd are not confined by SELinux, i.e. running
>> > with unconfined_t.
>> >
>> > During Flock I got asked whether we can change that and run systemd
>> > --user instances in some confined domain. Fixing this on systemd side
>> > should be trivial, i.e. we would have to add SELinuxContext= option
>> > with appropriate value to /usr/lib/systemd/system/user@.service (unit
>> > file used for spawning user instances of systemd).
>> >
>> > I am writing this email with a hope that we can discuss if above
>> > proposal even makes sense (what are possible gains from system
>> > security perspective) and if yes what is appropriate SELinux label to
>> > use (I guess we would need new one and define policy for it).
>>
>> Yes we should allow for systemd to specify a label, but the label needs
>> to be transitioned from the user domain.
>>
>> For example if I login as unconfined_t and want to run a service as
>> httpd_t, then I need to be able to transition from
>> unconfined_t to httpd_t.  As long as systemd-user is running as the user
>> domain, then SElinux will control this.
>
> That doesn't seem useful ;) Why would a user by able run anything as httpd_t?
> The way I understand Michal's question is: in what ways specifying a
> context for systemd --user that is different than current 
> unconfined_u:unconfined_r:unconfined_t
> would be actually useful? What general rules for transitions could be 
> provided?

My intuition is that, especially for non-root processes, using the
various sandboxing features available without MAC or any privileged
configuration (ProtectXYZ, namespaces, seccomp, etc) is already a good
deal easier to work with, more flexible, and less needing of
centralized policy than SELinux.  Maybe Fedora should focus on that
type of isolation for systemd user instances rather than trying to
make SELinux work for them.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Re: Snaps and Fedora

[Andrew Lutomirski]

On Jul 22, 2016 5:48 PM, "Neal Gompa"  wrote:
> This is done through the "plugs" and "slots" that can be used to
> create interfaces among them. This is a true superset of the
> capability provided by Flatpak through Portals, since it can be used
> to export non-DBus oriented communications mechanisms. This is
> described on the Snapcraft documentation[0].
>

I think (from reading the docs a bit -- I haven't tried it or looked at the
code) that snap interfaces are powerful but not in a good way for desktop
apps.  They seem to work a lot like Android permissions -- an app asks for
an interface and won't work without it.  The trouble is that they're very
coarse grained and grant global access.  I, as a user, don't want to give
my apps $HOME access, and I don't want apps written to expect $HOME
access.  Apps should automatically get permission to show a file open box
and get that file only.

Flatpak gets this right.

Admittedly, the Flatpak approach won't work directly for, say, a web
server.  But IMO it would much better if, instead of "network-bind", there
was "bind-port" and admins could connect their server to the specific port
it needed.

--Andy
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org