Re: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-17 Thread Björn Persson
Jakub Jelinek wrote:
> If there are bugs on the compiler side, please let me know immediately,
> so that those bugs can be fixed before the mass rebuild next week.

Certain Ada source files trigger what looks like infinite tail
recursion in add_sibling_attributes in dwarf2out.c:

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

Björn Persson


pgpaayNBpxRq6.pgp
Description: OpenPGP digital signatur
___
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: New tool - license-validate

2021-12-27 Thread Björn Persson
Miroslav Suchý wrote:
> $ license-validate-v'GPL or (MIT and BSD)'
>      No terminal defined for 'G' at line 1 col 1

Approximately nobody will understand "No terminal defined for 'G'". Can
the error message be improved?

Björn Persson


pgp5AIXhmHYUH.pgp
Description: OpenPGP digital signatur
___
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: new systemd in rawhide

2021-12-10 Thread Björn Persson
Zbigniew Jędrzejewski-Szmek wrote:
> This means that various libraries that were
> previously always pulled in, are not listed as Recommends by the various
> subpackages:
[...]
> Recommends are normally installed, but if you're using 'dnf --setopt 
> install_weak_deps=False'
> or similar, please make sure that you install those libraries too if 
> appropriate.

Was "not" supposed to be "now"? Otherwise these statements don't make
sense together.

Björn Persson


pgpz2V_ix2CZt.pgp
Description: OpenPGP digital signatur
___
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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

2021-12-09 Thread Björn Persson
Michel Alexandre Salim wrote:
> - do we want to allow any /local/ %wheel users to log in?

This seems fine to me.

> - or do we want to use a recovery passphrase of some sort?

I'm not sure what you mean here. When a passphrase is called a recovery
passphrase, it's usually because authentication is normally done
some other way. For example, if you normally log in by inserting some
kind of hardware token, then you may want a recovery passphrase to use
in case the hardware token is broken or lost.

As long as users normally log in with a passphrase, I see no need to
have a separate passphrase for rescue mode. Root's or a wheel user's
usual passphrase should be fine.

> For F36 - I agree that it's better to *not* have a rescue mode than a
> broken one. How about this as an end state we can realistically achieve:
> - if the root password is set, rescue mode should appear in the GRUB
>   menu
> - if the root password is not set
>   - rescue mode should not be listed
>   - if someone tries to invoke it, it should display an error rather
> than prompting for a non-existent password

This looks sane.

If there is a separate boot entry for the rescue mode, then maybe Grub
could be programmed to require a passphrase before it will boot that
entry?

Björn Persson


pgp1LnefA7iK9.pgp
Description: OpenPGP digital signatur
___
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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

2021-12-09 Thread Björn Persson
> A more user-friendly setup is to allow the password to be bypassed in
> case it's not set.
> 
> This does not pose an increased security risk:
> - you can already boot with `init=/sysroot/bin/bash` anyway
> - anyone with physical access to a machine can probably compromise it
> - you can enforce the need for a root password in single-user mode by setting 
> it

To disallow root login in normal operation, and then turn around when a
problem occurs and open a root shell without any login at all, is
inconsistent and will lead users to believe that their computer is more
secure than it actually is.

If Fedora is going to allow unauthenticated root access when there is a
boot problem, then for consistency the same should be true in normal
operation. Both root and other users should by default just be allowed
in without any authentication – not over SSH or any kind of network
access, but on local text consoles and GUI desktops. Anaconda's Root
Account page should be changed to make the root account enabled and
passphraseless by default, and on the User Creation page the checkbox
"Require a password to use this account" should be unchecked by
default. Anyone with physical access to a machine can probably
compromise it, so it's pointless to ask for passphrases on the console,
right?

*That* would be a change that users would be aware of, unlike the one
proposed in the Change proposal – and if users want to enforce the need
for a passphrase, then they can set one, on user accounts as well as on
the root account. When a root passphrase has been set, then that
passphrase should be required in all situations – normal operation,
rescue mode, single-user mode or whatever – and for consistency the
same passphrase should be required in Grub before the boot parameters
can be changed. A user who wants to enforce the need for a passphrase
should be able to do that in one place, not three.

Conversely, if it's considered correct that Anaconda forbids an open
passphraseless root account and promotes setting a passphrase on the
user account, then that policy should be applied consistently, even in
rescue mode. This makes a root passphrase necessary so that rescue mode
can work. Some day it may become possible to use a wheel user's
passphrase in rescue mode. Then, and not before, can the root account
be locked.

In this case, Grub should also by default require root's or a wheel
user's passphrase before boot parameters can be changed. That is
consistent.

Björn Persson


pgpcT9reGtFmi.pgp
Description: OpenPGP digital signatur
___
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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

2021-12-08 Thread Björn Persson
Chris Adams wrote:
> Once upon a time, Björn Persson  said:
> > Chris Adams wrote:  
> > > If the admin has done one thing to lock down the system, then they can
> > > do another (removing the sulogin --force addition).  
> > 
> > How do you propose to ensure that the admin is made aware of the need
> > to do that?  
> 
> The same way as any change - documentation.

Introducing a new security hole is not just a change like any other
change.

Sysadmins read documentation to find solutions when they know that they
have a problem to solve. They rarely read documentation to look for
problems they don't know about, and they don't regularly re-read every
document to look for potentially insecure changes.

> > Experienced sysadmins won't just instinctively know that in this new
> > release of this particular distribution they need to run this special
> > command to prevent boot problems from granting root access to whoever
> > can type on the keyboard.  
> 
> It's not a "special command", it's just removing an RPM

Po-tay-to, po-tah-to.

> I don't install a brand new OS and give it to users without checking it
> out myself

Does "checking it out" include breaking the system in every way you can
think of, to see whether one of them yields a root shell?

> (and reading at least the release notes).

Do you also read the release notes of all previous releases just in
case an obscure weakness was introduced in an old release that you
never used, and has been in place since then?

> This is NOT some new "hole" - out of the box, Fedora already allows
> someone with console access to get root access (in less convenient, but
> more confusing, ways).

What you're actually saying is: There is an old hole that we hope
sysadmins are aware of and know how to close if they need to, and
therefore it's fine to punch another hole in a hidden place where
sysadmins won't think to look.

Björn Persson


pgpjPAdAJ9zSj.pgp
Description: OpenPGP digital signatur
___
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: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

2021-12-07 Thread Björn Persson
Chris Adams wrote:
> If the admin has done one thing to lock down the system, then they can
> do another (removing the sulogin --force addition).

How do you propose to ensure that the admin is made aware of the need
to do that?

Experienced sysadmins won't just instinctively know that in this new
release of this particular distribution they need to run this special
command to prevent boot problems from granting root access to whoever
can type on the keyboard.

Björn Persson


pgpUpKi2TnP15.pgp
Description: OpenPGP digital signatur
___
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: F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)

2021-12-04 Thread Björn Persson
> * at build time, we compute the Merkle tree for the files within a
> package, then sign it and ship it as part of the rpm metadata;

[...]

> Note that the Merkle tree
> is ''not'' shipped with the RPM itself (only its signature is)

In that case, "ship it" above should be changed to "ship the signature",
unless this is some distinction between "the RPM metadata" and "the RPM
itself".

If I enable FS-verity and later find that I need to patch a file to fix
some problem, how do I as the sysadmin tell Linux that this change is
authorized? Do I disable FS-verity for that specific file? Disable
FS-verity globally? Add my own key to the kernel's keyring? Build and
sign my own RPM package?

What prevents an attacker from doing the same?

Will files under /etc be covered, or will local configuration still be
possible?

Björn Persson


pgpbMIhTbl4rJ.pgp
Description: OpenPGP digital signatur
___
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: (Quite?) OT Question: Is still relevant Software RAID?

2021-12-02 Thread Björn Persson
Sergio Belkin wrote:
> Do you think that (Linux) Software RAID is still relevant in this "breve
> new world" of cloud/devops ?

There are still some people who don't want some cloud to live their
life for them. If anything would make software RAID irrelevant, it
would be ZFS and BTRFS, not clouds or devops. But the licensing
situation makes ZFS painful, and BTRFS seems to take forever to mature,
so it should be expected that many people will choose software RAID
instead.

Björn Persson


pgpK9xoq79ydL.pgp
Description: OpenPGP digital signatur
___
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: Review request for oclock package (orphaned since F35)

2021-11-23 Thread Björn Persson
Ben Beasley wrote:
> Please compare with 
> https://src.fedoraproject.org/rpms/xfontsel/blob/rawhide/f/xfontsel.spec, 
> paying close attention to the comments in the spec file. SKS keyservers have 
> gone offline since that package obtained its keyring, so try using 
> hkps://keys.openpgp.org instead.

To elaborate on this, the procedure described in xfontsel.spec finds the
key that was used to make the signature, so whoever made the signature
becomes the trusted upstream.

If you do that *once*, it's a form of trust on first use. It lets you
discover future attacks as long as you continue using the same key,
assuming that you got the right key to begin with.

If you would repeat the key lookup every time you upgrade the package,
then you would render the verification meaningless. You'd just be
verifying that the tarball was signed by whoever signed the tarball. So
don't do that.

Björn Persson


pgpuxCuE5BI4x.pgp
Description: OpenPGP digital signatur
___
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: F36 Change: Remove .la files from buildroot (Self-Contained Change proposal)

2021-11-01 Thread Björn Persson
> Pull request implementing `%__brp_remove_la_files` in the upstream rpm
> repository: https://github.com/rpm-software-management/rpm/pull/1674

This looks like it risks deleting more files than intended. If some
package uses country codes or domain names in filenames, then this
change could silently delete files specific to Laos.

Language codes occur as filename suffixes. Apache can use them to serve
web pages in the client's preferred language. This change risks deleting
files written in latin.

If there is a more reliable way to recognize a Libtool archive by
inspecting the file's content, then I think the script should do that
to verify that files with a ".la" suffix really are Libtool archives
before deleting them.

Björn Persson


pgp2yAnXNNShR.pgp
Description: OpenPGP digital signatur
___
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: crypto-policies and a certain usage of SHA-1

2021-10-16 Thread Björn Persson
Michael Catanzaro wrote:
> SHA-1 is blocked in certificate signatures because those can be 
> attacked offline. Signatures in the TLS handshake are entirely 
> different. I'm hardly an expert, but I think the attacker only has a 
> few seconds to generate a hash collision before the user gives up and 
> closes the browser tab. Spending several months trying to find a 
> collision is not an option here. Am I wrong?

Probing the server repeatedly I get the same value in the Pubkey field
several times in a row. Some time later the value changes. The server
seems to replace the key every few hours or days. The Signature field
is different every time though. Thus I'm not sure whether the
attacker's time limit is the lifetime of the key (which Fedora can't
control) or the TCP timeout.

Björn Persson


pgptnItUABZ9M.pgp
Description: OpenPGP digital signatur
___
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


crypto-policies and a certain usage of SHA-1

2021-10-15 Thread Björn Persson
Hello, I have a question for someone with deep knowledge about
cryptology. The question regards Fedora's crypto policies and a certain
usage of SHA-1 in TLS.

I encountered a web server that Seamonkey and Firefox refuse to talk
to. Both give me the error SSL_ERROR_UNSUPPORTED_SIGNATURE_ALGORITHM.

In an attempt to find out more, I checked the server with Qualys' SSL
Server Test (https://www.ssllabs.com/ssltest/). Qualys gave it an A+,
which is supposed to mean that its security is excellent.

Next I used Wireshark to inspect the TLS handshake. Wireshark reported
usage of SHA-1, not in the certificate but in a signature associated
with elliptic curve parameters:

| TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
| Content Type: Handshake (22)
| Version: TLS 1.2 (0x0303)
| Length: 333
| Handshake Protocol: Server Key Exchange
| Handshake Type: Server Key Exchange (12)
| Length: 329
| EC Diffie-Hellman Server Params
| Curve Type: named_curve (0x03)
| Named Curve: secp256r1 (0x0017)
| Pubkey Length: 65
| Pubkey: 
041f840f40a2178f875274097092ca2549138f8a7bd52df895ea413b742d1714a6cf873e…
| Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
| Signature Hash Algorithm Hash: SHA1 (2)
| Signature Hash Algorithm Signature: RSA (1)
| Signature Length: 256
| Signature: 
09147d81aa601dc402e62cf7f943196c89822a0c8bbe07d8443654519b0e04f51b0b8e72…

To check whether this was the problem, I temporarily added "SHA1" to
/etc/crypto-policies/back-ends/nss.config. This made the error go away,
and the browser happily loaded the page.

My question is: Is it true that this usage of SHA-1 makes the TLS
session weak, so that it's correct to forbid it in the crypto policy?
Or could it be that Qualys is right? Perhaps SHA-1 is fine for this use
case, even though it's too weak for other use cases, and the crypto
policy should allow it?

The website where I saw this is https://www.euroclear.com/ in case
anyone wants to test things themself.

Björn Persson


pgptX2bBu9PZE.pgp
Description: OpenPGP digital signatur
___
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: Linux Plumbers Conference - Open Printing Micro Conference

2021-09-21 Thread Björn Persson
Zdenek Dohnal wrote:
> the schedule for the first no-driver was proposed

What is a no-driver?

Björn Persson


pgp8IziBk8gfn.pgp
Description: OpenPGP digital signatur
___
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: Specfile description and summary translations

2021-08-19 Thread Björn Persson
Otto Urpelainen wrote:
> I am also afraid that for rpms, current tooling makes success 
> impossible: nothing tracks when the main Summary is changed and flags 
> translations as outdated, and any volunteer translator would have to 
> endure a dist-git pull request workflow to contribute fixes.

Yes, translators would need some translation tool that flags outdated
translations and doesn't require pull requests to each and every
package.

For package maintainers who know some non-English language, it's much
more convenient to write a translation in the spec file than to first
update the package and then switch to some other tool to update the
translation. The current RPM tooling works well for them.

Years ago there were translations of RPM descriptions and summaries
that originated from somewhere other than spec files. I don't know what
tools were used to produce those, but they seemed to coexist peacefully
with translations from spec files. They don't seem to exist anymore. The
few translations I can find now all come from spec files.

The disappearance of those external translations indicates that the
Fedora Project no longer cares about translations of RPM descriptions
and summaries, which is sad, but in that case there certainly shouldn't
be a "SHOULD" in the Review Guidelines.

Björn Persson


pgpCtFKpUoKUK.pgp
Description: OpenPGP digital signatur
___
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: Systemd unit files installed into unowned directories

2021-08-05 Thread Björn Persson
Petr Menšík wrote:
> No, that is the reason why I proposed it. Guidelines already state
> *-filesystem packages does not have to be depended on [1]. Just one,
> probably systemd or systemd-libs, should depend on it to get it
> installed. All other can then just ignore the directory exactly as you
> have proposed. In this case it would not be breaking guidelines, but
> according to them instead.
> 
> 1.
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership

That is contradicted by the following quote from the Packaging
Guidelines:

| Sometimes, it may be preferable for such directories to be owned by
| an "artificial filesystem" package, such as mozilla-filesystem. These
| packages are designed to be explicitly required when other packages
| store files in their directories, thus, in such situations, these
| packages should explicitly Require the artificial filesystem package
| and not multiply own those directories.

That is, each of those 1600 packages would need to require
systemd-filesystem.

Perhaps the filesystem package should own these directories? Not
systemd-filesystem, just filesystem. The case is rather similar to
/usr/share/bash-completion, /usr/share/man, /usr/share/info and various
other directories that filesystem owns.

Björn Persson


pgpM1c3jmu0yS.pgp
Description: OpenPGP digital signatur
___
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: Why so long for EPEL-8?

2021-07-19 Thread Björn Persson
Vitaly Zaitsev via devel wrote:
> On 18/07/2021 13:38, Neal Gompa wrote:
> > 1. People don't give feedback and only complain after the fact.  
> 
> On Fedora too. Only a few popular packages (kernel, firefox, 
> thunderbird) get user feedback on Bodhi. All others will need to stay in 
> testing for 7 days.

I suspect that many users are like me: I don't want to constantly be a
guinea-pig for the whole testing repository, but if I could be notified
about updates of certain packages I'm interested in, then I could
choose to test those if I'm not too busy at the time. I don't know a
convenient way to do that, so I end up installing updates when they
show up in the updates repository.

Björn Persson


pgpvoA3f6hGTK.pgp
Description: OpenPGP digital signatur
___
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: Using "Open location" in GIMP causes a (sometimes) catastrophic crash

2021-06-19 Thread Björn Persson
Josef Řídký wrote:
> From my point of view, it's ok, if the GIMP ends with an error message
> explaining something like - No such file. This is actually written in the
> super long alert window that pops up.
> 
> What is not so good are the cases, when GIMP crashes. They might be caused
> by limited system resources. From the provided error message it looks
> like insufficient RAM/buffer size.

Perhaps limiting the length of the error message could prevent overuse
of system resources? I doubt anyone actually wants a super-wide alert
window.

Björn Persson


pgpM5f6yNwkaN.pgp
Description: OpenPGP digital signatur
___
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: x86_64-v2 in Fedora

2021-06-16 Thread Björn Persson
Stephen John Smoogen wrote:
> #!/usr/bin/awk -f
> 
> BEGIN {
> while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
> if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 
> 1
> if (level == 1 &&
> /cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2
> if (level == 2 &&
> /avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/)
> level = 3
> if (level == 3 &&
> /avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
> if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 }
> exit 1
> }

That script says "x86-64-v1" on my previous workstation, which is now a
server. But I'm already planning to reinstall that one with Debian, to
get less upgrade churn while keeping Ada and ZFS, so it won't hurt me
if Fedora stops working there.

Björn Persson


pgptuEq6E5mQJ.pgp
Description: OpenPGP digital signatur
___
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: Preventing supply chain attacks via rekor

2021-06-11 Thread Björn Persson
Huzaifa Sidhpurwala wrote:
> I am sure everyone has heard about the recent Solarwinds software supply 
> chain attacks. This attack has made all software vendors think about 
> securing their supply chain,  and it is even more applicable to linux 
> distributions which are made of thousands of components built from 
> sources they dont even have control over.

Yes, there is much that could be improved in this area.

> One possible step in this direction is the ability to ensure that there 
> is no distribution point tampering of binaries shipped in Fedora.

What would "distribution point" mean here? Repository mirrors? The
master repository? mirrors.fedoraproject.org?

> this could be a post-build thing, in which ones the rpms reach 
> stable and are signed, rekor would run on it and store the binary 
> metadata in the transparency logs.

As it is now, mirrors can't modify RPM packages without a key that the
clients have installed. Mirrors could however withhold security updates
so that clients remain vulnerable. Is that a thing that Rekor could
prevent?

I believe Yum has a feature to verify signed repository metadata. I
don't know why it's not used. If that verification would be turned on,
are there any attacks that would still be possible then, that Rekor
could prevent?

> More information at:
> 
> https://sigstore.dev/what_is_sigstore/

On that page I can't see anything but a page header and a pointless
animation. Even the text that is right there in the HTML code is hidden.
Instead it wants me to execute a bunch of Javascript from at least three
different domains. When a website expects me to execute some unknown
program before they'll even tell me who they are or what they do, then
I'm much more likely to just ignore that website.

Björn Persson


pgpkB9LKZss3D.pgp
Description: OpenPGP digital signatur
___
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: When is pappl going to be good enough to replace cups?

2021-05-27 Thread Björn Persson
Solomon Peachy wrote:
> If all you want to do is prevent CUPS from auto-discovering 
> remote printers, edit /etc/cups/cupsd.conf and set 'Browsing Off'

"Browsing" is documented as "Specifies whether shared printers are
advertised". That sounds like printers on this host are advertised to
other hosts on the network, but if that's what the parameter does, then
"Browsing" is a misleading name for it.

Is it supposed to mean that printers shared by other hosts are
"advertised" in print dialogs on this host? That would be a very strange
use of both "shared" and "advertised", but would agree better with
"Browsing".

It also looks like "Browsing" is redundant with "BrowseLocalProtocols",
which is documented as "Specifies which protocols to use for local
printer sharing". For any reasonable reading of the manual,
"BrowseLocalProtocols none" should have the same effect as "Browsing
No". It seems safest to turn off both, but I'm not at all sure whether
that prevents network printers from showing up in my print dialogs.

Björn Persson


pgp6atBpTr1Cr.pgp
Description: OpenPGP digital signatur
___
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: When is pappl going to be good enough to replace cups?

2021-05-26 Thread Björn Persson
Solomon Peachy wrote:
> On Wed, May 26, 2021 at 08:15:46PM +0200, Björn Persson wrote:
> > And I always try to avoid using protocols that assume that the local
> > link is secure. That's one of the reasons why my printer is connected by
> > USB, and I would like to continue to have that choice.  
> 
> You have always had (and always will) have that choice; the ability to 
> disable automatic printer discovery has been present since discovery was 
> added with CUPS 1.2 (released back in 2006!)

I'll have to see if I can find that option. Thanks for the hint.

Björn Persson


pgpLUW8ag8A8D.pgp
Description: OpenPGP digital signatur
___
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: When is pappl going to be good enough to replace cups?

2021-05-26 Thread Björn Persson
Stephen John Smoogen wrote:
> The truth is that most people know about it, and have decided that they can
> go 'meh' and keep living.

I am well aware that most people don't think for a second about computer
security. I see examples every day. They tend to begin caring after they
find out that they personally have been owned.

So your argument is that programs should be written insecurely to make
the few who care as insecure as the majority? I shouldn't even have the
option to care about security? Otherwise I don't see how what you wrote
is an argument in this debate.

> Instead IPP, LPD and other
> print protocols have always been written with the assumption that the local
> network is some level of secure.

And I always try to avoid using protocols that assume that the local
link is secure. That's one of the reasons why my printer is connected by
USB, and I would like to continue to have that choice.

Björn Persson


pgp2GJIq_HFQB.pgp
Description: OpenPGP digital signatur
___
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: When is pappl going to be good enough to replace cups?

2021-05-26 Thread Björn Persson
Solomon Peachy wrote:
> Those that do appear show up as "queuename at host" or 
> "mfg_model_hostname"

I can trust that they always contain either the string " at " or two
underscores? Or is that just what well-behaved printers do, while an
attacker can name their fake printer however they want?

> (for native IPP printers, there's usually a partial 
> MAC address in there by default too)

Security has no use for "usually".

> Queues you create 
> manually/permanently can be called whatever you want and point wherever 
> you want.

So if I see a print queue whose name contains neither the word "at" nor
any underscores, is that a guarantee that it's a manually configured
queue? In that case I may be able to keep my configured queue and know
that I'm sending to my USB printer (or, I guess, redo the configuration
when I'm forced to wrap a web server around the USB printer). But the
existence of two different naming schemes makes me suspect that there
is no such guarantee.

I thought for a while that I could configure an unguessable queue name
to let me distinguish between my own print queue and the attacker's, but
that won't work. A DNS rebinding attack would let the attacker read the
queue name from CUPS' web interface, so I can't rely on the queue name
being secret.

> CUPS's auto-discovery mechanisms have _always_ assumed the 
> local network can be trusted.

You mean CUPS _already_ allows an attacker on the local link to
impersonate my USB printer, even before it starts wrapping web servers
around USB printers? That's disappointing, but at this point I'm quite
ready to believe it.

> Sure, someone could be spoofing a specific printer name/identifier just 
> so they can capture a document *you* want to print, but if there's that 
> level of persistant hostile presence on your local network, you're 
> already completly screwed.

I would be if I would use insecure protocols on that network – but I
stopped using Telnet, SMB and FTP at home decades ago.

Björn Persson


pgpeiVdE4m7Yl.pgp
Description: OpenPGP digital signatur
___
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: When is pappl going to be good enough to replace cups?

2021-05-25 Thread Björn Persson
Kevin Kofler via devel wrote:
> Zdenek Dohnal wrote:
> > CUPS discovery is designed to run on secure, private LAN, so it is
> > expected that you have a protection against somebody connecting to your
> > WIFI.  
> 
> That is (still) a reasonable assumption for a home WiFi WLAN on which a home 
> printer is likely to be located. That is what WPA is for.
> 
> Sure, you can connect a notebook or smartphone to untrusted public WiFi 
> networks, but you normally do not print in such a network.

None of that answers the question: How can I tell whether the printer
I'm sending to is on an untrusted network, on an imaginary network
created for a USB printer, or on a 1980s-style isolated LAN? Will the
name of the network interface be displayed when I choose a printer?
Will there at least be a visible difference between a permanently
configured printer and an auto-found printer, so I can continue to have
my printer configured and know that I'm sending to that one?

Do I need to explain, detail by detail, the errors in the reasoning
"People don't print on untrusted networks. Therefore any network with a
printer on it is trusted.", or can people see the logical flaws on
their own?

Björn Persson


pgpQrJpctJGuj.pgp
Description: OpenPGP digital signatur
___
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: When is pappl going to be good enough to replace cups?

2021-05-24 Thread Björn Persson
Zdenek Dohnal wrote:
> CUPS discovery is designed to run on secure, private LAN, so it is
> expected that you have a protection against somebody connecting to your
> WIFI.

That was a reasonable assumption in the 1980s. It's 2021 now, and every
program that communicates must cope with a hostile environment.

Here in the third millennium we have laptops moving between networks.
There are public hotspots and mobile Internet, plenty of connections
that aren't private LANs. Home routers are typically crap and never get
any security updates, and the Insecurity of Things ensures that there
are easily cracked devices in every home and office. As for wifi, it
has a long history of flawed security protocols. A recent study found
three protocol design flaws in the standards, including the latest WPA3
specification, and nine implementation defects that can be used to
attack devices that trust the wifi network to protect them. Assuming
that all the nodes on the local link are friendly is criminally naïve.

Björn Persson


pgpLHHjA7RfBz.pgp
Description: OpenPGP digital signatur
___
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: When is pappl going to be good enough to replace cups?

2021-05-22 Thread Björn Persson
Stephen John Smoogen wrote:
> On Fri, May 21, 2021 at 18:19 Kevin Kofler via devel <
> devel@lists.fedoraproject.org> wrote:  
> 
> > Zdenek Dohnal wrote:  
> > > The purpose of the library is have a way how to implement a support for
> > > devices which don't support IPP Everywhere [2] or its derivations
> > > (Airprint, Mopria, Google cloud print) or IPP over USB[3], so they can
> > > be seen by CUPS once we remove printer driver support.  
> >
> > I really don't see how the switch from drivers to printer applications is
> > an
> > improvement. All the existing drivers have to be ported to the new
> > interface
> > to essentially emulate the IPP protocol.
> 
> Yes it is a bad situation but I don’t think there are a set of ‘CUPS’
> developers versus one person trying to keep the software going. Apple
> stopped supporting the product and msweet is working for himself now.
> lprint seems to be a ‘make a best out of a bad situation’.

So what I'm hearing is that Fedora will soon stop working with my
printer, because if there isn't enough manpower to even keep existing
printer drivers in place, then who is going to write a bunch of pappls
for not-quite-brand-new printers?

And if the bright and shiny future is that USB printers look just like
network printers, and network printers just show up without any
installation, then I'm starting to wonder how I will know whether I'm
sending my sensitive document to my USB printer or to some impostor on
a wifi network.

I wish working software could just continue working. Obviously that's
far too sane for this insane world.

Björn Persson


pgpN_tzgp_dVv.pgp
Description: OpenPGP digital signatur
___
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: Upgrade to Fedora 34 broke the boot menu.

2021-05-11 Thread Björn Persson
Adam Williamson wrote:
> Do you have any idea what went wrong? I don't recall hearing of anyone
> else having this trouble, yet. And we've definitely had pre-BLS
> installs upgraded, as people hit the GNOME login bug on them...

The current hypothesis is that the system was using and updating
/boot/grub2/grub.cfg, leaving /boot/efi/EFI/fedora/grub.cfg to go stale,
and the upgrade replaced the file in use with the stale one.

This would mean that different programs have different ideas about
which grub.cfg is in use.

See also https://bugzilla.redhat.com/show_bug.cgi?id=1958540

Björn Persson


pgpX3XiSBtS43.pgp
Description: OpenPGP digital signatur
___
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: Upgrade to Fedora 34 broke the boot menu.

2021-05-09 Thread Björn Persson
My boot menu is now repaired.

I replaced /boot/grub2/grub.cfg with the following:

insmod part_gpt
insmod ext2
search --no-floppy --fs-label --set=root speedy.boot2
insmod blscfg
blscfg

That was good enough to find the kernel and get Fedora going. (Keeping
all the partitions labeled pays off in situations like this.) Then I
ran "grub2-mkconfig -o /boot/grub2/grub.cfg" to get the boot working
normally.

Björn Persson


pgpOIohB2HgVJ.pgp
Description: OpenPGP digital signatur
___
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: Upgrade to Fedora 34 broke the boot menu.

2021-05-08 Thread Björn Persson
Alexander Ploumistos wrote:
> Have you looked in /boot/loader/entries/ ? I don't know how they get
> created, but a couple of times I've had some extra entries after an
> upgrade - nothing older than Fedora N-2 though.

It contains files that seem to match the menu entries I should get,
none of the outdated entries I actually see.

Björn Persson


pgpz23pXbFgYJ.pgp
Description: OpenPGP digital signatur
___
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: Upgrade to Fedora 34 broke the boot menu.

2021-05-08 Thread Björn Persson
Chris Murphy wrote:
> Does /etc/default/grub contain
> GRUB_ENABLE_BLSCFG=false
> ?

No, it says "GRUB_ENABLE_BLSCFG=true".

> There have been two big GRUB changes and if you followed them without
> any intervention or customizations, you get upgraded correctly. If you
> make customizations or opt out, then those are pretty much not tested
> by anyone. So you've probably discovered a bug.

I've customized the kernel parameters to unhide the boot messages to be
able to see what's happening when something goes wrong. I also need to
fix various problems at times. I always struggle to figure out the
proper way to update the boot menu or the initramfs when necessary. If
the instructions I found at some point in the past weren't quite right,
then I suppose I may have had some non-canonical configuration.

> Recreate /boot/grub2/grub.cfg

That file contains the outdated menu entries I described. Is there a
way to recreate it from the Dracut shell, or with the filesystem
temporarily mounted on another Fedora 32 system?

Björn Persson


pgpwCgzgHgw6P.pgp
Description: OpenPGP digital signatur
___
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: Upgrade to Fedora 34 broke the boot menu.

2021-05-08 Thread Björn Persson
Tomasz Torcz wrote:
> Dnia Sat, May 08, 2021 at 02:51:31PM +0200, Björn Persson napisał(a):
> > I used yum system-upgrade to upgrade from Fedora 32 to Fedora 34. Now
> > Grub complains about not finding some theme files, and then displays a  
> 
>   Missing theme files sounds like 
> https://bugzilla.redhat.com/show_bug.cgi?id=1944571
>   (Error message during boot about missing fireworks.png)

If only that one file is missing for you, then I think my outdated boot
menu is another bug.

Björn Persson


pgpl2MnGUuNP2.pgp
Description: OpenPGP digital signatur
___
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: Upgrade to Fedora 34 broke the boot menu.

2021-05-08 Thread Björn Persson
Neal Gompa wrote:
> On Sat, May 8, 2021 at 8:53 AM Björn Persson  wrote:
> >
> > I used yum system-upgrade to upgrade from Fedora 32 to Fedora 34. Now
> > Grub complains about not finding some theme files, and then displays a
> > menu with two kernels from Fedora 29 and a rescue entry from Fedora 28.
> > If I choose one of the Fedora 29 entries, then Grub unsurprisingly
> > fails to find the kernel. The rescue entry actually boots to some kind
> > of shell, after printing lots of timeout messages, but getting from
> > there to a working system will be a major research project for me.
> >
> > The menu also has entries for "advanced flags" (or something like that;
> > not sure what it would be in English) and "tboot". Both lead to other
> > menus with boot entries from Fedora 25.
> >
> > The boot partition contains three sets of vmlinuz, initramfs, config
> > and System.map files – one fc34 set and two fc32 sets as expected – but
> > Grub has apparently reverted to a years-old boot menu program.
> >
> > Which component in Bugzilla might be responsible for this mess?
> >  
> 
> That's probably grub2.

OK, I filed a bug report against grub2.

Björn Persson


pgpk9__mFcJGh.pgp
Description: OpenPGP digital signatur
___
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


Upgrade to Fedora 34 broke the boot menu.

2021-05-08 Thread Björn Persson
I used yum system-upgrade to upgrade from Fedora 32 to Fedora 34. Now
Grub complains about not finding some theme files, and then displays a
menu with two kernels from Fedora 29 and a rescue entry from Fedora 28.
If I choose one of the Fedora 29 entries, then Grub unsurprisingly
fails to find the kernel. The rescue entry actually boots to some kind
of shell, after printing lots of timeout messages, but getting from
there to a working system will be a major research project for me.

The menu also has entries for "advanced flags" (or something like that;
not sure what it would be in English) and "tboot". Both lead to other
menus with boot entries from Fedora 25.

The boot partition contains three sets of vmlinuz, initramfs, config
and System.map files – one fc34 set and two fc32 sets as expected – but
Grub has apparently reverted to a years-old boot menu program.

Which component in Bugzilla might be responsible for this mess?

Björn Persson


pgpbycvIEd1Uy.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: CompilerPolicy Change (System-Wide Change proposal)

2021-04-23 Thread Björn Persson
> The policy update will also recommend that packagers use standardized
> macro names when using conditional options to control the compiler
> choice:
> 
> %bcond_with toolchain_clang
> %bcond_with toolchain_gcc

[...]

> Note this change is only for compiler selection.  It does not change
> existing policies WRT runtime library selection, linker selection,
> debuggers, etc.

Should the macro names really contain "toolchain" if they only select
the compiler? "Toolchain" suggests to me that they swap out the whole
toolchain including preprocessor, compiler, assembler, linker and
whatever else may be involved.

Björn Persson


pgp_UDSFlTZ8_.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

2021-04-22 Thread Björn Persson
Frank Ch. Eigler wrote:
> Björn Persson  writes:
> > And as you noted yourself, an attacker who can manipulate cached files
> > client-side has already taken over the user account anyway.  
> 
> Yes and no, and so I must disagree with your "won't improve ... for
> anyone".  The proposed client-side verification is roughly analogous to
> running "rpm -V" on a machine.  Yes, if an attacker has control at that
> moment, it's not reliable.  Nevertheless, to detect residue of a
> -previous attack- or accidental data corruption, it can be worthwhile.

I fail to imagine how you believe attackers operate to make the
distinction between an attacker who has control and a previous attack
relevant.

It can detect accidental data corruption, yes. If you want to checksum
the cache to detect accidental data corruption, that's fine by me, but
that's better done locally, so that the checksums can be verified
without contacting any server.

> > Given that it serves debuginfo only for Fedora packages, and does not
> > forward requests to any other debuginfo servers, using this server
> > seems equivalent security-wise to downloading unsigned packages from
> > Koji.  
> 
> Not exactly.  All the data is -from- signed packages.

Okay, so it's equivalent to downloading packages that were once signed, 
but had the signatures removed before the packages were offered for
downloading – which is in turn equivalent to downloading unsigned
packages.

> > To make the debuginfo protocol as secure as signed debuginfo packages,
> > the client should verify the files against a hash computed and signed
> > on the signing server.  
> 
> If the threat model includes a -local active attacker-, then this would
> not help either.  An attacker could interfere with the local keystore
> and/or trust chains and/or signature verification software.

A local active attacker who can already read, write and execute
whatever they want has nothing more to gain from tampering with cached
debuginfo.

> > By the way, the change page still doesn't say enough about how network
> > problems will affect the user experience. [...]  
> 
> I'm not sure why you say "still" when this question was not posed here
> before.

Because I posed the question in my first message in this thread, on the
11th.

Björn Persson


pgpXG48MZ2oBY.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

2021-04-22 Thread Björn Persson
Frank Ch. Eigler wrote:
> "Sampson Fung"  writes:
> 
> > The first run, giving my "Try"s, takes much longer than the second run, 
> > which gives no "Trys".
> > Just from impression:
> > 1st run:  From run to download finish, I will say it takes about 5+ minutes.
> > 2nd run: ~1 minute
> > For each "Try" given, the delay is not obvious to me.  
> 
> I'm pretty sure Sampson was affected by a proxy.stg.fedoraproject.org
> misconfiguration problem that was fixed about an hour ago, so those
> timeouts should not be happening any more.

It is however a good illustration of how a network problem can destroy
the user experience. Five minutes is a long wait. I'm glad that we now
have this information.

Björn Persson


pgpaB8snU3QuR.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

2021-04-21 Thread Björn Persson
FUNG Chi Chuen Sampson wrote:
> While trying to collect a backtrace for org.gnome.Tetravex, I got this in gdb:
> 
> ===
> 
> Downloading separate debug info for /lib64/liblzma.so.5...
> Download failed: Timer expired.  Continuing without debug info for 
> /lib64/libbrotlicommon.so.1.
> Missing separate debuginfo for /lib64/libbrotlicommon.so.1
> Try: dnf --enablerepo='*debug*' install 
> /usr/lib/debug/.build-id/0e/bb3270fdbf40dbe56ea79d6630ac594b897ffe.debug
> Download failed: Timer expired.  Continuing without debug info for 
> /lib64/libzstd.so.1.
> Missing separate debuginfo for /lib64/libzstd.so.1
> Try: dnf --enablerepo='*debug*' install 
> /usr/lib/debug/.build-id/33/70d80a1bf749b3c2baaad0188c864ee9e4bbc4.debug
> Downloading separate debug info for /lib64/liblz4.so.1...
> Download failed: Timer expired.  Continuing without debug info for 
> /home/fcc/.var/app/org.gnome.Tetravex/cache/debuginfod_client/a2429c266188acc10181f6936915f35274bb4a38/debuginfo.
> Error while reading shared library symbols for /lib64/liblz4.so.1:
> could not find '.gnu_debugaltlink' file for 
> /home/fcc/.var/app/org.gnome.Tetravex/cache/debuginfod_client/a2429c266188acc10181f6936915f35274bb4a38/debuginfo
> Downloading separate debug info for /lib64/libcap.so.2...

I was wondering what the user experience would be like in such a
situation. Could you estimate how long you had to wait in total? Was
there a long delay before each "Timer expired" message, or only one
delay?

Björn Persson


pgpkyJGGu6Vvi.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

2021-04-21 Thread Björn Persson
Frank Ch. Eigler wrote:
> Björn Persson writes:
> 
> > · How is it verified that files received from debuginfo servers have not
> >   been tampered with?  
> 
> Following up further to this, we're planning to add optional client-side
> hash-verification of cached content, to provide some protection against
> tampering:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=27758

The design you propose there won't improve anything for anyone. If the
hash is computed on the debuginfo server, then an attacker who can make
the server serve malicious debuginfo can also make it serve hashes that
match the malicious files. And as you noted yourself, an attacker who
can manipulate cached files client-side has already taken over the user
account anyway.

Quote from Sourceware Bugzilla:
> As transport over HTTPS protects the content, we can safely assume
> that immediately during/after the download, the content will be fine.
> However, what of cached files?

Of course – from your point of view. From my point of view, I can safely
assume that nobody has tampered with my cache. However, what of files on
the debuginfo server?

I see that debuginfod.fedoraproject.org is currently another name for
koji.fedoraproject.org. Given that it serves debuginfo only for Fedora
packages, and does not forward requests to any other debuginfo servers,
using this server seems equivalent security-wise to downloading unsigned
packages from Koji.

As far as I understand, packages are built and signed on separate
servers with a smaller attack surface than the web front-end to minimize
the risk that an attacker could tamper with them. To make the debuginfo
protocol as secure as signed debuginfo packages, the client should
verify the files against a hash computed and signed on the signing
server.

Perhaps a hash of the debuginfo could be stored in a signed RPM package,
either the main package or a separate debughash package?

For those who are concerned about privacy, the proposal would make that
problem worse as it would cause the "phoning home" to happen every time
they debug something.

By the way, the change page still doesn't say enough about how network
problems will affect the user experience. Making a previously offline
activity network-dependent also makes it sensitive to network problems.
For example, if great packet loss causes TCP timeouts or long delays,
will that make GDB hang for minutes at a time, or is it handled
asynchronously? Will GDB hang once per process, once per login session,
or every time it encounters a new source filename?

Björn Persson


pgpd6o8sweyXG.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: Debuginfod By Default (Self-Contained Change proposal)

2021-04-10 Thread Björn Persson
> https://fedoraproject.org/wiki/Changes/DebuginfodByDefault

The change page lacks a discussion of security implications. An informed
decision requires answers to questions such as:

· What kinds of attacks might be possible with malicious debuginfo files?
  (For example debugging tools might have undiscovered bugs that could be
  exploited by malformed DWARF data.)

· How is it verified that files received from debuginfo servers have not
  been tampered with?

· Is there any end-to-end authentication from the Fedora build system to
  my workstation – which there is with signed debuginfo packages – or do
  the tools blindly trust a whole network of federated debuginfo servers?

> Some Debian users have
> [https://lists.debian.org/debian-devel/2021/02/msg00262.html expressed
> concerns] that this facility "calls home" during debugging, so it may
> expose a limited amount of information about what a user is debugging.

To fully understand the privacy implications, one needs to know:

· Does that happen every time, or are downloaded files cached locally?

· If there is a cache, when are old files purged from the cache?

The change page should also mention how a network problem can impact the
usability of debugging tools. Could it for example make GDB hang for a
minute every time it encounters a new source filename?

Finally, if somebody doesn't like the answers to the above questions,
then they'll want to know how to disable the feature.

Björn Persson


pgpoMb6YRGooA.pgp
Description: OpenPGP digital signatur
___
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


License changes in Gnatcoll packages

2021-04-09 Thread Björn Persson
Starting with Fedora 34, several Gnatcoll subpackages have licenses
that include the GCC Runtime Library Exception. The License fields
have therefore changed as follows:

gnatcoll-core, gnatcoll-iconv, gnatcoll-syslog, gnatcoll-sql,
gnatcoll-sqlite and gnatcoll-postgres have changed from GPLv3+ to
GPLv3+ with exceptions.

gnatcoll-gmp, gnatcoll-readline and gnatcoll-xref are still GPLv3+.

Björn Persson


pgpuCeu2ODDUt.pgp
Description: OpenPGP digital signatur
___
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: F35 Change proposal: RPM 4.17 (System-Wide Change proposal)

2021-04-07 Thread Björn Persson
Panu Matilainen wrote:
> I'm starting to think the right thing to do is to move %check to run 
> after %build rather than %install.

Here's one thing that would be affected by such a change:

https://docs.fedoraproject.org/en-US/packaging-guidelines/Ada/#_runpaths

Our Ada packaging policy has a requirement to run check-rpaths at the
end of %check to guard against runpaths slipping into packaged files.
It was added on the FPC's request. They wanted it to run as late as
possible. Here's the discussion for reference:

https://meetbot.fedoraproject.org/teams/fpc/fpc.2013-12-19-17.02.log.html

check-rpaths checks files in RPM_BUILD_ROOT, so it would have to be
moved to the end of %install if %check would run before %install.

I'm aware that there's a proposal to run check-rpaths automatically on
all packages:

https://pagure.io/packaging-committee/issue/886

I think that's a good idea. If it gets implemented, then we can remove
check-rpaths from the Ada spec files – but there might be other similar
usecases where something runs in %check to check files in the buildroot,
which would break if %check would be moved before %install.

Björn Persson


pgpfJE5qbRvw7.pgp
Description: OpenPGP digital signatur
___
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 Account Migration & Production Deployment Update: COMPLETE!

2021-03-28 Thread Björn Persson
stan via devel wrote:
> e.g.  What is your favorite food?  Jamaica.

Acceptable for human-to-human interaction, but falls quickly to a
dictionary attack if verification is automated.

> or What was your team's name in high school?  0126672651361

43 bits of entropy if all the digits are random; decent strength but
not great.

> I suppose it could be a passphrase, but this is easier to cut and
> paste.

We're talking about a backup secret. You're not supposed to use it every
day. It's not a problem if it takes a few seconds to copy it the one
time you actually need it. That said, if you don't want spaces in your
passphrase, then just write it without spaces:

What is your favorite food?
sleepyarsenicblimpswithgranitechipsandlewdPCB

> How about everyone has two logins, and they have to log in with
> different logins from the same device, using different passwords.  They
> then are considered to be authenticated.  That uses the existing
> infrastructure of password managers to keep passwords secure, and just
> requires two logins on the site being logged into; should be easy
> enough.  Less secure than a real second factor, but more secure than a
> single password.  I suppose if we consider that too much trouble, just
> add a second password to the single login everywhere.  Even less secure
> than the two login method, though.

Requiring two passwords might somewhat mitigate the problem of naive
users believing that a word like "Jamaica" is useful as a password – if
it's checked server-side that the two passwords are not similar – but
it's not two-factor authentication if both passwords are stored in the
same password manager.

I'm not going to speculate on how you mean that "two logins" would
differ from two passwords.

Björn Persson


pgpkoANwBrvz0.pgp
Description: OpenPGP digital signatur
___
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 Account Migration & Production Deployment Update: COMPLETE!

2021-03-27 Thread Björn Persson
Kevin Fenzi wrote:
> I'd like us to add security query/respond pairs. 

Those can very easily weaken security, as the answers are often public
and easy for an attacker to look up, especially when there are only a
few predefined questions to choose from.

If I can enter my own question, then I can come up with some things
that only I and my family know. That requires careful and security-
conscious consideration. Many people would come up with insecure
questions.

There's a limited supply of such personal secrets that I can be sure
I'll remember, so I can't do that for too many sites. It also requires
a not too public life. People who publish their entire lives on
Facebook will have trouble coming up with a question that an attacker
can't find the answer to.

Otherwise I'll make up a nonsensical phrase to enter as the answer, and
store it securely. That turns the "security question" into a backup
passphrase. If you want people to do this, then it's better to ask them
to make up a passphrase.

Björn Persson


pgpE8zuWQSxko.pgp
Description: OpenPGP digital signatur
___
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 Account Migration & Production Deployment Update: COMPLETE!

2021-03-27 Thread Björn Persson
Tomasz Torcz wrote:
> I meant push notification, when the message is sent through secure channel
> to your smart phone and you get popup asking for authorization.

The Swedish BankID cartel did that in their proprietary app, and thus
enabled an outbreak of fraud. Here's how it works:

1: The fraudster calls the victim, posing as the bank or some authority
figure, and tells some confidence-inspiring lies. Then the fraudster
says that they need to ascertain the victim's identity.

2: The fraudster initiates a login to the victim's bank account.

3: The bank sends an authentication request to the victim's BankID app.
A popup is displayed on the victim's smartphone.

4: The victim is expecting an authentication request from the person
they're talking to, and sees a request that seems to match, so they
grant the request.

5: The bank receives a correct authentication response. The fraudster
is now logged in to the victim's account.

The design flaw is that the authentication happens in a side channel,
separate from the login session. The bank doesn't know whether the
remote ends of the two channels are in the same place. Correct design
is to do the authentication in the login session itself. For a
workaround one can tie the two channels together somehow, and that's
how the Swedish banks patched the flaw. They now display a QR code on
the login page that the user must photograph with their smartphone,
thereby tying the authentication channel to the login session. I hear
the QR code is optional for websites, so anything that uses BankID
authentication and doesn't use the QR code is still vulnerable.

Now, if the side channel is only used as a second authentication, and
the first authentication, with the passphrase, is done in the login
session, then successful attacks will be less frequent, because then
the attacker first needs the victim's passphrase. Side-channel
authentication is a design flaw none the less. There's no point to
having a second factor if it's so weak that the security depends mostly
on the first factor.

Björn Persson


pgpdjMBn7aR77.pgp
Description: OpenPGP digital signatur
___
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 Account Migration & Production Deployment Update: COMPLETE!

2021-03-26 Thread Björn Persson
Christopher wrote:
> * Unlike many other implementations, there is no backup code option
> (GitHub, Google, others, provide 10 one-time use backup codes you can
> use in case you don't have access to your authenticator app; these can
> be regenerated after a successful login).

It seems that the backup is to send an OpenPGP-signed email to an admin
address. That's acceptable as long as the admins take care to properly
verify the OpenPGP key – but since Noggin stores only key IDs (and
truncates them incorrectly), I'm left wondering what methods they'll try
if they need to look up my key. Will they try WKD? DNS? Is there a
specific key server that must have my key for me to be able to recover
my Fedora account if I lose my second factor?

> * In many places, including accounts.fedoraproject.org, in order to
> log in, you have to append the OTP to your password, so it doesn't
> really play nice with password managers.

Such kludges shouldn't be exposed in user interfaces if it can be
avoided. A web interface should be able to receive two strings in two
separate fields, and concatenate them if the backend requires that.

Björn Persson


pgpCioe8trQ5A.pgp
Description: OpenPGP digital signatur
___
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: OpenSSH SHA-1 deprecation, developing FAQ, etc

2021-03-12 Thread Björn Persson
Petr Pisar wrote:
> V Fri, Mar 12, 2021 at 10:53:01AM +0100, Miroslav Suchý napsal(a):
> > Do I understand it correctly that soon, I will have trouble connecting to
> > 
> >   $(grep ssh-rsa ~/.ssh/known_hosts | cut -f1 -d' ')
> > 
> > hosts?
> > Should I regenerate the ssh key there? What is the prefered crypto nowadays?
> >   
> No. Your keys do not use SHA at all. SSH protocol when performing
> authenticated key exchange can use SHA. It's a matter of SSH server and SSH
> client.

To expand on this, "ssh-rsa" seems to mean two things. It's a key type,
and also a signature scheme. ssh-rsa keys are still good (if they're
long enough). The signature scheme ssh-rsa, on the other hand, uses
SHA-1 and therefore needs to be replaced.

If both client and server are OpenSSH 7.2 or later, and an ssh-rsa key
is involved, then one of the newer signature schemes rsa-sha2-256 and
rsa-sha2-512 will be used, and you won't have any trouble.

If both client and server are OpenSSH 6.5 or later, but one is older
than 7.2, then you may need an ssh-ed25519 key so that the signature
scheme ssh-ed25519 can be used.

At least that's how I understand it. It's very confusing, because users
usually only see "ssh-rsa" as a key type, but the release notes assume
that the reader knows about signature schemes in the SSH protocol.
Inconsistent terminology certainly doesn't help. The release notes seem
to use "signature scheme" and "signature algorithm" interchangeably,
and the manual uses "host key algorithms" and "key types" when it seems
to actually be talking about signature schemes.

Björn Persson


pgpueXa4thwTm.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: "Fedora Linux" in /etc/os-release

2021-03-10 Thread Björn Persson
Matthew Miller wrote:
> Of course, the obvious response is that it hasn't stuck. That might be
> partly true, but it also definitely _has_ for other people (see for example
> the `httpd` package naming in our own repos)

Debian, on the other hand, has an apache2 package, /usr/sbin/apache2,
/etc/apache2, apache2.service and so on. That's a real nuisance.
Working with both Debian and CentOS I always have trouble remembering
whether it's /etc/apache2 or /etc/httpd, and apache2.service or
httpd.service. Both have apachectl though, not httpctl.

Björn Persson


pgpM4JMCrkspm.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: "Fedora Linux" in /etc/os-release

2021-03-10 Thread Björn Persson
Matthew Miller wrote:
> leading to things like
> people saying "Oh, that's in CoreOS, not Fedora", where the shorthand is
> more confusing than helpful.

What should that be instead? "That's in CoreOS, not Linux" is no better.
"That's in Fedora CoreOS, not Fedora Linux" makes no sense either,
because Fedora CoreOS would be a subset of Fedora Linux if I understand
you correctly.

Björn Persson


pgp4m8hB5HQ1s.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: "Fedora Linux" in /etc/os-release

2021-03-10 Thread Björn Persson
Vitaly Zaitsev via devel wrote:
> 2. Why Linux and not GNU/Linux? Linux is just a kernel. GNU/Linux is an OS.

It was very predictable that this argument would happen, and that's why
I've been quite happy that Fedora is just "Fedora" with no "Linux" in
the name.

If we're going to name the distribution after some of its components,
why stop at one or two? Arguably the most central part of any software
distribution is its package manager. The programs that bring up the
whole system are also rather important. And none of the GUI programs
would exist without the windowing system so we need to mention X. Or
should that honor go to Wayland now? Better give them equal treatment.

"Fedora GNU/Linux/RPM/Python/DNF/SystemD/Xorg/Wayland/..."

It's better to give the whole distribution its own name, and not name
it after any of its components. Fedora is a software distribution. It
contains Linux, many GNU components, RPM, MariaDB, Libreoffice and lots
of other things, but its name is "Fedora". Or call it "Fedora Software
Distribution" or anything else that doesn't single out any of the
components. That approach seems to minimize the political fighting.

Björn Persson


pgpzWvb0QUWvj.pgp
Description: OpenPGP digital signatur
___
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: F35 Change: "Fedora Linux" in /etc/os-release

2021-03-10 Thread Björn Persson
> We make EPEL, ELN, and thousands of packages in Copr. These are all part of
> Fedora — but aren't Fedora Linux. We also make artwork, music,
> documentation, videos, websites, tools, and more. These things too are part
> of our project, but aren't part of the Fedora Linux distribution.

ELN also contains Linux, doesn't it? EPEL doesn't contain Linux, but
Linux will always be present in the system when a package from EPEL is
used.

> When referring to our work, please use either a
> specific name like Fedora Workstation, Fedora CoreOS, or
> Fedora KDE Plasma Desktop; or use Fedora Linux to refer to
> the OS distribution as a whole.

I don't think "Linux" conveys the distinction between those things and
ELN. Someone who hears "Fedora Linux" won't understand that it comprises
both Workstation and CoreOS but not ELN. It would be better to come up
with another word to denote a collection of software distributions that
aren't "enterprise" distributions, and also not art, websites et cetera.
A word that captures the essence of how the things it covers differ from
all the other things.

Maybe something like "Fedora Family", because it's a number of closely
related distributions which are suitable for use at home?

Or something like "Fedora Flow", alluding to frequent releases and a
steady stream of updates?

Björn Persson


pgpQIZfjHla23.pgp
Description: OpenPGP digital signatur
___
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: python noarch packaging vs pip install

2021-03-08 Thread Björn Persson
Mattia Verga via devel wrote:
> I'm just wondering: what's the benefit of packaging Python noarch
> projects in Fedora?
[...]
> In what way is different from installing them by pip?

· Users can install and use programs without caring about what
programming language they are written in.

· Programs can depend on other programs written in other languages.

· Users don't need to run pip to check for Python program updates, cpan
to check for Perl program updates, npm to check for Javascript program
updates, gem to check for Ruby program updates, and so on and so forth.
They can get all their updates with a single "yum update".

· It's easy to set traps on PyPI that trick users into downloading
malware. I've never heard about any such problem in the Fedora
repository.
https://arstechnica.com/information-technology/2016/06/college-student-schools-govs-and-mils-on-perils-of-arbitrary-code-execution/
https://arstechnica.com/information-technology/2017/09/devs-unknowingly-use-malicious-modules-put-into-official-python-repository/
https://arstechnica.com/information-technology/2018/10/two-new-supply-chain-attacks-come-to-light-in-less-than-a-week/
https://arstechnica.com/information-technology/2021/02/supply-chain-attack-that-fooled-apple-and-microsoft-is-attracting-copycats/

Björn Persson


pgplQo4tEGPPu.pgp
Description: OpenPGP digital signatur
___
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's GPG key in DNS(SEC)

2021-03-08 Thread Björn Persson
Martin Sehnoutka wrote:
> This system has other advantages as well:
>   * it can automatically install keys for 3rd party repos and verify 
> them using the DNSSEC trust anchor which is preinstalled on the system

RPM Fusion is an example of such a third-party repo. To use packages
from RPM Fusion you'll first manually download and install the
rpmfusion-free-release package, which contains the repo files and keys.

Suppose a bad guy has somehow tricked you into downloading a malicious
version of rpmfusion-free-release. The package is signed by
brad.guy@malicious.example, and the key is published in the domain
malicious.example. All the DNSsec signatures are in perfect order, so
you can be quite sure that the key really does belong to
brad.guy@malicious.example. Do you trust Brad? Should you install the
package?

Obviously we want a package signed by an attacker to fail the
verification. Section 3 of your thesis describes how the modified DNF
uses DNSsec to verify that the key is valid for the stated email
address, but I don't see anything about how it decides whether the
email address is correct for the repository, or whether the person
behind that email address is trusted. You state that the DNS server
isn't necessarily in the same domain as the repository, so it's not as
simple as comparing the domain names. Could you explain how the email
address is validated?

Björn Persson


pgpKpG3Y0YPHa.pgp
Description: OpenPGP digital signatur
___
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: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

2021-03-08 Thread Björn Persson
Matthew Miller wrote:
> On Sun, Mar 07, 2021 at 10:26:50AM +0100, Björn Persson wrote:
> > > It can, but most people don't have a good setup for even local mail
> > > delivery. Out of the box, we don't really do anything useful.  
> > It wouldn't take much. Install Postfix, and when Anaconda creates the
> > first user account, have it add a mapping from root to that username in
> > /etc/aliases. Then a variety of MUAs can pick up the emails from
> > /var/spool/mail.  
> 
> Well but even then the user needs to know to look for local mail. That's not
> a normal expecation for even many Linux folks these days.

Unless their MUA does that by default. I'm not sure how many do. I can't
think of any strong reasons to have it disabled.

I once had a problem with local email disappearing on a freshly
installed laptop. It turned out that Seamonkey was picking it up and
moving it to its own mail directory. That was not so good because I was
using Seamonkey only as a browser, not for mail. If it had waited until
I opened Seamonkey Mail before picking up local mail, then I would have
been quite happy about it.

Gmail users would miss it I suppose. There are some disadvantages to
relying on web services for everything.

Björn Persson


pgpSLErgP4erY.pgp
Description: OpenPGP digital signatur
___
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: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

2021-03-07 Thread Björn Persson
Hans de Goede wrote:
> But for MCE exceptions, specifically ECC errors I would expect the kernel to 
> log these
> through dmesg anyways and then the mcelog service has very little added value 
> IMHO
> (I have no experience with machines with ECC RAM).
> 
> Esp. given that ECC RAM is something which most Fedora Workstation users won't
> have, so having this included / enabled by default feels wrong IMHO.

Well, to get x86-64 with ECC you need to choose AMD, or else an Intel
processor marketed for big hefty servers, but MCE catches more errors
than just memory bit errors. Do the ECC-less Intel processors also lack
all other MCE support?

On my ECC-capable Ryzen workstation, mcelog is not started because
/sys/module/edac_mce_amd/initstate exists. Apparently the daemon is
considered unnecessary when this kernel module is active. On the other
hand there's a kernel thread called "edac-poller", so I don't know
whether the runtime overhead is any lower.

Björn Persson


pgpxIV_q_B1uk.pgp
Description: OpenPGP digital signatur
___
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: F34 gdm login prompt goes crazy when a fingerprint reader with no enrolled prints is present

2021-03-07 Thread Björn Persson
Matthew Miller wrote:
> On Fri, Mar 05, 2021 at 05:12:34PM +0100, Tomasz Torcz wrote:
> > smartd even sends emails – that's how I was informed
> > about one of my disks dying, few weeks ago,  

I thought it would send email, but then I noticed that it's started
with "--capabilities", which breaks email notification according to the
manpage, so now I don't know what to believe.

It does indeed seem much less useful if it can't send email. Unless
Logwatch picks up the warnings from the log? But that again requires
local email.

> It can, but most people don't have a good setup for even local mail
> delivery. Out of the box, we don't really do anything useful.

It wouldn't take much. Install Postfix, and when Anaconda creates the
first user account, have it add a mapping from root to that username in
/etc/aliases. Then a variety of MUAs can pick up the emails from
/var/spool/mail.

But I guess those who want fewer daemons won't be happy to see Postfix
added just for a chance to be warned about an imminent breakdown.

Björn Persson


pgpK7UBRzp74e.pgp
Description: OpenPGP digital signatur
___
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: Bodhi client prompting for a password

2021-03-03 Thread Björn Persson
Fabio Valentini wrote:
> On Wed, Mar 3, 2021 at 9:31 PM Miro Hrončok  wrote:
> >
> > On 03. 03. 21 21:08, Florian Weimer wrote:  
> > > I want to run this command:
> > >
> > >bodhi updates trigger-tests FEDORA-2021-279dee1742
> > >
> > > But I'm prompted for a username and password.  I have a working Kerberos
> > > setup for koji/fedpkg, so this is somewhat surprising.  Is this
> > > expected?  
> >
> > Yes, that is how bodhi CLI client works.  
> 
> Yes. Sadly, most Fedora projects use different methods for
> authenticating with your FAS account.
> 
> koji uses kerberos, bodhi uses OpenID over HTTP, dist-git uses SSH ...

It wouldn't be a user interface problem if they'd all fetch the
passcode from the same keyring. Then the user wouldn't need to know how
many different protocols are used under the hood.

Björn Persson


pgpa5S1G_mGtl.pgp
Description: OpenPGP digital signatur
___
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's GPG key in DNS(SEC)

2021-02-12 Thread Björn Persson
Miroslav Suchý wrote:
> All Fedora's GPG key - starting with Fedora 27 - are now stored in 
> fedoraproject.org DNS record and can be verified 
> using DNSSEC.
> 
> Why? How it can be used? That is long story and you can read about it in my 
> blog entry:
> 
> http://miroslav.suchy.cz/blog/archives/2021/02/11/verify_package_gpg_signature_using_dnssec/index.html

More checking doesn't hurt, but mostly this looks like a different
solution to a problem that Fedora already has a solution to. The
changes to DNF aren't an answer to the question in your blog post:

> But how to fetch the very first GPG key?

The first key that gets imported to RPM is included in the installation
image and gets installed along with the rest of the system, but that's
not the very first key. The very first OpenPGP key is the one you need
to verify the installation image before you start the installation.
(Okay, technically the same key is used for both purposes, but that's
an irrelevant detail.)

If you install from a malicious installation image, then your Fedora
system is already compromised before DNF has a chance to look up any
key. On the other hand, once the image is verified you can trust its
contents, including the keys that will later be used to verify
downloaded packages. (Assuming of course that you can trust the computer
you used to verify the image, and the USB memory you write it to. It's
trust all the way down.)

Verifying the installation image isn't a thing that RPM and DNF can help
you with. That may well need to happen on a non-RPM-based system. What
would help is if GnuPG could fetch and verify the key automatically. (It
would also help if we had detached OpenPGP signatures of the images so
we could skip the sha256sum step.) According to the manual, GnuPG can
look up keys in DNS in various ways, but it tries only Web Key Directory
by default. I think therefore that the greatest advantage of publishing
the keys in DNS is that it can help with verifying installation images,
but it might be even better to publish them in a Web Key Directory.

Björn Persson


pgp4dEThCZaHC.pgp
Description: OpenPGP digital signatur
___
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: Jami (formerly Ring) P2P softphone packaging?

2021-02-02 Thread Björn Persson
Daniel Pocock wrote:
> What is the problem with ffmpeg?  I couldn't find any reference to it in
> DuckDuckGo search results.

The problem is in the USA's patent system. FFMPEG contains
patent-encumbered code.

> Maybe the Jami client can be built without video support, if it only
> does voice and IM could that provide a way forward?

If that would remove the dependency on FFMPEG, then I suppose that
would work around that problem at least.

You could also try packaging Jami in RPM Fusion, if FFMPEG is the only
obstacle.

Björn Persson


pgp2kmhXTqIh7.pgp
Description: OpenPGP digital signatur
___
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: Schedule for Wednesday's FESCo Meeting (2021-01-13)

2021-01-13 Thread Björn Persson
Zbigniew Jędrzejewski-Szmek wrote:
> I'm not sure why it's in UTC and not some DST zone. It might even have
> been on purpose.

I wasn't involved in that decision but I can tell you one simple and
obvious reason to specify times in UTC: Everybody needs to know only
their own current offset from UTC, and can convert to their local time
with a single addition.

If a time and an offset are specified, then everybody needs to subtract
that offset and then add their own offset, so that requires slightly
more mental arithmetic.

If an acronym like "HKT" is given instead of an offset, then everybody
must either know what offset that acronym stands for, or look it up
before they can convert the time. That's much less friendly to the
reader.

Even worse is to specify a timezone by geographical name. Then the
reader needs to find out whether time jumps are practised in that zone,
and on what days, before they can know what the offset is in that zone
at the time. Then they can subtract that offset, and finally add their
own offset. Times specified this way will also be ambiguous each time
that timezone jumps backwards.

So obviously UTC works best for agreeing on a meeting time across
borders.

Björn Persson


pgpVdptJ6P7EG.pgp
Description: OpenPGP digital signatur
___
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: Stale proven packagers

2020-12-26 Thread Björn Persson
Gary Buhrmaster wrote:
> Arguably those with elevated access (provenpackagers(*))
> should be required to use a hardware token such
> as a FIDO2 authenticators with biometrics and/or
> PIN required

I'm in favor of complementing the FAS passphrase with a second factor.

I'm against any attempt to require biometrics. These are my reasons:

· Biometric identifiers aren't cleanly separated from identity. They
are more akin to your username than to your passphrase. A random key or
a passphrase can be revoked and replaced if it gets out. Fingers and
faces are very difficult to replace. And yes they can get out. Once
your fingerprint has been scanned and turned into data, those data can
be copied like any other secret. You also leave your fingerprints on
everything you touch.

· Such a requirement is unenforceable. A client can never prove to a
server that it has a certain piece of hardware. It can only prove that
it knows a certain secret – or two secrets since we're talking about
two-factor authentication. Whether the secrets are stored on a hard
disk, in a Yubikey, in somebody's brain or in somebody's retina, is
unknown to the server. Before authentication it must be assumed that
the client may be an attacker who is lying about everything they can
lie about. Some protocol might allow the client to claim that it used a
fingerprint reader, but as far as the server knows the attacker might
just be using a stored scan of the real user's fingerprint.

· Biometrics is low-grade security for use where convenience takes
precedence. If somebody can't remember a good PIN, then it's better for
them to unlock their phone with their fingerprint than to choose ""
for their PIN. Strong crypto keys and hardware tokens are better where
security requirements are higher, like in two-factor authentication.
Requiring biometrics is effectively the same as prohibiting stronger
authentication methods, which is a stupid thing to do.

Björn Persson


pgpUh0Z_Vy5p9.pgp
Description: OpenPGP digital signatur
___
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: Nothing provides libgnat-10.so()(64bit)

2020-12-08 Thread Björn Persson
Miro Hrončok wrote:
> On 12/8/20 10:26 AM, Björn Persson wrote:
> > This time I got eight separate Bugzilla issues, which all essentially
> > just served as notification that GCC has been upgraded, and each one
> > needs to be closed manually. That's manageable as long as the number of
> > Ada packages is small, but it still feels like unnecessary work.  
> 
> Note that the bugzillas also close automatically.

OK, that's better then. Apparently I've gotten used to automation not
doing that.

Björn Persson


pgp0u4_8S6YpF.pgp
Description: OpenPGP digital signatur
___
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: Nothing provides libgnat-10.so()(64bit)

2020-12-08 Thread Björn Persson
Jeff Law wrote:
> On 12/7/20 11:07 AM, Jakub Jelinek wrote:
> > On Mon, Dec 07, 2020 at 06:29:51PM +0100, Miro Hrončok wrote:  
> >> Hello. Apparently, many packages in rawhide require 
> >> libgnat-10.so()(64bit):  
> > I'm not a provenpackager, so I'm afraid I can't do that myself.
> > Perhaps the maintainers can just rebuild them themselves?  
> And note that some of these are going to require fixes to the packages
> themselves as the Ada front-end changed and some of them no longer
> build.  IIRC zlib and templates_parser are the most important to get
> rebuilt and I think those "just work".
> 
> I'll try to get those rebuilt so that the downstream things have a
> better chance of working :-)

I'm rebuilding my packages now. Generally speaking, if someone who is
involved in GCC maintenance, and also has the necessary privileges,
would rebuild the Ada packages when GCC is upgraded, that would be
helpful.

I can also set off the rebuilds myself, but it really helps to be
notified when it's time. Some years I haven't noticed when a new GCC
landed in Rawhide, until the following mass rebuild started reporting
failures (because mass rebuilds aren't done in dependency order).

Long ago I used to get email notifications about uninstallable
packages. That was better than not being notified, but one email per
package was a little unnecessary. A single email would suffice.

This time I got eight separate Bugzilla issues, which all essentially
just served as notification that GCC has been upgraded, and each one
needs to be closed manually. That's manageable as long as the number of
Ada packages is small, but it still feels like unnecessary work.

Of course, if one of my packages is unbuildable (and it's not just
because its dependencies haven't been rebuilt yet), notify me and I'll
look into it. For that purpose a bug report in Bugzilla is appropriate.

Björn Persson


pgpBqSuNykGKA.pgp
Description: OpenPGP digital signatur
___
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 34 Change: ntp replacement (Self-Contained Change)

2020-12-03 Thread Björn Persson
> == Upgrade/compatibility impact ==
> 
> The `ntp` package is replaced automatically on upgrade to Fedora 34.
> The configuration file ''/etc/ntp.conf'' is saved as to
> ''/etc/ntp.conf.rpmsave'' and it needs to be renamed to
> ''/etc/ntp.conf'' to be used by `ntpsec`. Otherwise, `ntpsec` will
> fall back to the default configuration in ''/etc/ntp.d'' using the
> ''pool.ntp.org'' servers.
> 
> The `ntpd` service is disabled after the upgrade and needs to be enabled 
> again.

That's not so nice to those users who can use NTPsec as a drop-in
replacement. For them it would be better to keep the configuration file
and have the service enabled if it was enabled before the upgrade.

Users who use some feature that NTPsec has dropped will have to adjust
their configuration either way. Everyone else should get their drop-in
replacement dropped in if possible.

What harm could it cause if the configuration file and the service were
tranparently transferred for all users? If the configuration file uses
any of the dropped features, then NTPsec should at worst refuse to run.
If it does anything worse than that, then I think that's a serious
defect that needs to be fixed.

> == User Experience ==
> For most users of `ntp` the experience is not expected to change
> significantly.

Or rather: For most users their only experience will be that their
clocks will drift until they un-rename the configuration file and
reenable the service?

Björn Persson


pgpp5LBDN7tg3.pgp
Description: OpenPGP digital signatur
___
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: Package review sum-ump

2020-11-24 Thread Björn Persson
ycollette.nos...@free.fr wrote:
> I posted (by mistake) 2 packages review for this package ...
> https://bugzilla.redhat.com/show_bug.cgi?id=1893711
> https://bugzilla.redhat.com/show_bug.cgi?id=1887709

Then close one as a duplicate of the other. Because the newer one is
assigned to a reviewer, it's probably best to close the older one as
duplicate.

Next time you write to the list, don't reply to a random unrelated
message. Use the reply button only when you're actually replying to
something.

Björn Persson


pgpvqQxcz9TqU.pgp
Description: OpenPGP digital signatur
___
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: Rawhide build failure on strange archs

2020-11-07 Thread Björn Persson
Steve Dickson wrote:
> So I change the sprintf() to an snprintf() [2] guaranteeing no
> overflow and I got the same failure.

Not quite the same. It still doesn't know how long the string can be,
and so assumes that it can be too long, but after the change it warns
about truncation instead of overflow.

Björn Persson


pgpkFWYt_eIDv.pgp
Description: OpenPGP digital signatur
___
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 Security Team

2020-11-04 Thread Björn Persson
Stephen Gallagher wrote:
> Generally, whenever Node.js issues a security release, they do so for
> multiple issues simultaneously. When Product Security then goes and creates
> Bugzilla tickets, they create many (sometimes up to five bugs per CVE). It
> becomes nearly impossible to keep up with the bug maintenance in such
> situations. The process is just too heavyweight and I often end up just
> doing the upstream releases and ignoring the BZs.
> 
> If we want this to be more accurate, we really need to have a more
> streamlined and/or automated solution for these issues.

Of course, the real solution would be decent code quality upstream, so
that security fixes would be rare, not come in heaps.

Björn Persson


pgpNFhNBPaTcI.pgp
Description: OpenPGP digital signatur
___
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: Retiring ntp

2020-11-02 Thread Björn Persson
Miroslav Lichvar wrote:
> The main problem is that they don't fix all known security issues. In
> the CVE list I see about 10 issues that were not fixed at all or only
> partially, some exploitable in default configuration.

That sounds bad. Where is that list? In Red Hat Bugzilla I see only two.

> I'm not sure how many users of ntp are there. As a replacement, we
> could package ntpsec.

Judging only from their own website, it seems that switching to NTPsec
would be a great improvement.

I'll have to investigate whether I can migrate all my usecases to
Chrony.

Björn Persson


pgpwYLWhtsbwn.pgp
Description: OpenPGP digital signatur
___
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: F34 Change proposal: DNS Over TLS (System-Wide Change)

2020-10-08 Thread Björn Persson
Michael Catanzaro wrote:
> On Thu, Oct 8, 2020 at 1:28 pm, Paul Wouters  wrote:
> > I agree for two reasons. One, the FESCO decision to postpone making
> > systemd-resolvd the default resolver. I would like to ensure this
> > change happens properly and securely for f34.  
> 
> Well it's too late, since we are now in final freeze. FESCo reaffirmed 
> the systemd-resolved change just last week, so it's clearly not going 
> to be postponed. I agree that this DNSSEC problem with systemd-resolved 
> is unfortunate, and I'm sure the systemd developers would appreciate 
> help fixing it. Anyway, the best time to deal with this would have been 
> six months ago, when the change was proposed

The DNSsec problem was brought up by Florian Weimer and Tom Hughes six
months ago, when the change was proposed. Fesco or the change owners
could have chosen to "deal with" the problem then, if they cared about
DNSsec. You Michael replied to Florian and called DNSsec-aware clients
"a quite specialized use-case", so you can't claim that you were unaware
of the issue. "It's too late" rings hollow coming from someone who had
the chance to do something when it wasn't too late.

Björn Persson


pgp9q1oKjfcMf.pgp
Description: OpenPGP digital signatur
___
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: fedpkg push - traceback - and a PR created?

2020-10-04 Thread Björn Persson
Sérgio Basto wrote:
> On Sun, 2020-10-04 at 21:39 +0200, Björn Persson wrote:
> > Adam Williamson wrote:  
> > > On Sun, 2020-10-04 at 12:31 +0200, Vitaly Zaitsev via devel wrote:  
> > > > On 04.10.2020 12:04, Barry Scott wrote:
> > > > > Why is a PR being created? I'm the maintainer and have not seen
> > > > > this before.
> > > > 
> > > > It just suggests you to create a pull request. Just ignore.
> > > 
> > > Right. It's not saying a pull request *has been created*, it's
> > > giving
> > > you a URL that *would create a pull request* (after confirmation)
> > > if
> > > you clicked on it.  
> > 
> > Obviously the message is unclear. Instead of "Create a pull-request",
> > it would be better if it said "You can create a pull-request here:".
> >   
> It says "create" which means "you may create" ...

Read literally it means "you shall create".

Björn Persson


pgpUFxSJ1TdmF.pgp
Description: OpenPGP digital signatur
___
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: fedpkg push - traceback - and a PR created?

2020-10-04 Thread Björn Persson
Adam Williamson wrote:
> On Sun, 2020-10-04 at 12:31 +0200, Vitaly Zaitsev via devel wrote:
> > On 04.10.2020 12:04, Barry Scott wrote:  
> > > Why is a PR being created? I'm the maintainer and have not seen this 
> > > before.  
> > 
> > It just suggests you to create a pull request. Just ignore.  
> 
> Right. It's not saying a pull request *has been created*, it's giving
> you a URL that *would create a pull request* (after confirmation) if
> you clicked on it.

Obviously the message is unclear. Instead of "Create a pull-request",
it would be better if it said "You can create a pull-request here:".

Björn Persson


pgpyFM46RxEdz.pgp
Description: OpenPGP digital signatur
___
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

2020-09-30 Thread Björn Persson
Michael Catanzaro wrote:
> On Wed, Sep 30, 2020 at 6:43 pm, Dominik 'Rathann' Mierzejewski 
>  wrote:
> > What if I'm using NetworkManager and dnssec-trigger? This has been
> > working very well for me for the last couple of releases and I'd hate
> > to be forced to manually reconfigure things so that it starts working
> > again.  
> 
> The upgrade process is designed to do the right thing for users who 
> stick with our defaults. Manual intervention is required for unusual 
> cases like this. You'll need to manually disable systemd-resolved after 
> upgrade, restore /etc/resolv.conf from the backup file that will be 
> created during upgrade, and restart NetworkManager. That would look 
> something like:
> 
> # systemctl disable systemd-resolved.service
> # systmectl stop systemd-resolved.service
> # mv /etc/resolv.conf.orig-with-nm /etc/resolv.conf
> # systemctl restart NetworkManager.service

So there's no need to revert any changes to /etc/nsswitch.conf? I've
seen some discussion about that file in relation to systemd-resolved.
It seemed far from easy to understand how to make it work correctly.

Björn Persson


pgp5_2mAhEYOs.pgp
Description: OpenPGP digital signatur
___
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

2020-09-30 Thread Björn Persson
Neal Gompa wrote:
> On Tue, Sep 29, 2020 at 7:48 AM Björn Persson  wrote:
> >
> > Lennart Poettering wrote:  
> > > On Mo, 28.09.20 22:54, Björn Persson (Bjorn@rombobjörn.se) wrote:
> > >  
> > > > It can work in company-scope if the company has competent network
> > > > admins. My local DNS server at home resolves local hostnames to private
> > > > IPv4 addresses in the 192.168/16 block. Clients on the Internet see
> > > > another view. Both views are DNSsec-signed, and validation works fine.
> > > > There's no reason why this setup wouldn't work on a corporate network.
> > > > The key is to use a domain that is actually registered to the company,
> > > > not some made-up TLD like "internal" or whatever the incompetent
> > > > network admins come up with.  
> > >
> > > You never take your laptop outside to a cafe or so? You never
> > > connected it to something that is not your home or office network?  
> >
> > A cafe is company-scope? I'm not sure whether that counts as moving the
> > goalposts or changing the subject, but neither is a constructive way to
> > discuss a technical topic.
> 
> If you're a remote employee, it absolutely is. And especially in this
> pandemic, this kind of thing is now the *default* experience.

So we're assuming that we have successfully connected to the company
VPN, as the company-scope DNS isn't involved unless we have access to
the company network. The cafe's network may be crappy, but evidently not
so bad that our VPN can't work. Now, how exactly does the cafe prevent
us from sending queries with the DO bit set through the VPN tunnel to
the company-scope DNS server and receiving security records in the
response?

Lennart claimed that "propagating DO stuff as is cannot work for [...]
company-scope DNS". I'm saying that claim is false. If you can't use
the cafe scenario to prove me wrong, then the cafe is irrelevant. To
have a constructive technical discussion it is necessary to keep
separate issues separate.

Björn Persson


pgpvq986NjQ8p.pgp
Description: OpenPGP digital signatur
___
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

2020-09-29 Thread Björn Persson
Lennart Poettering wrote:
> On Mo, 28.09.20 22:54, Björn Persson (Bjorn@rombobjörn.se) wrote:
> 
> > It can work in company-scope if the company has competent network
> > admins. My local DNS server at home resolves local hostnames to private
> > IPv4 addresses in the 192.168/16 block. Clients on the Internet see
> > another view. Both views are DNSsec-signed, and validation works fine.
> > There's no reason why this setup wouldn't work on a corporate network.
> > The key is to use a domain that is actually registered to the company,
> > not some made-up TLD like "internal" or whatever the incompetent
> > network admins come up with.  
> 
> You never take your laptop outside to a cafe or so? You never
> connected it to something that is not your home or office network?

A cafe is company-scope? I'm not sure whether that counts as moving the
goalposts or changing the subject, but neither is a constructive way to
discuss a technical topic.

Björn Persson


pgpCpXVpKWKG2.pgp
Description: OpenPGP digital signatur
___
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

2020-09-28 Thread Björn Persson
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.

It can work in company-scope if the company has competent network
admins. My local DNS server at home resolves local hostnames to private
IPv4 addresses in the 192.168/16 block. Clients on the Internet see
another view. Both views are DNSsec-signed, and validation works fine.
There's no reason why this setup wouldn't work on a corporate network.
The key is to use a domain that is actually registered to the company,
not some made-up TLD like "internal" or whatever the incompetent
network admins come up with.

>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.

It would make more sense to select the "personality" based on what
interface the client uses, than based on a DO flag in the query:
Present actual standards-compliant DNS and nothing else on UDP and TCP
port 53, and return your own synthesized stuff to programs that call
getaddrinfo (and through the D-Bus interface I suppose).

Nobody connects to port 53 expecting to get entries from /etc/hosts or
LLMNR. Programs that do this expect only DNS – and they're likely to
expect advanced DNS features to work, because they would have just
called getaddrinfo if they weren't interested in advanced features. It
could even be argued that returning non-DNS data through the DNS
protocol is wrong, but if you can do it without violating DNS standards,
then I don't think it will hurt.

>systemd-resolved is not supposed to be a real DNS *server*.

A real DNS server is however what existing programs expect to find in
/etc/resolv.conf.

>Until we implement the DO-bypass stuff, there's an easy way to bypass
>systemd-resolved for your DNSSEC resolver needs: just symlink
>/run/systemd/resolve/resolv.conf to /etc/resolv.conf (i.e. instead of
>/run/systemd/resolve/stub-resolv.conf). If you do that all local DNS
>clients will use the upstream DNS servers resolved picked up directly,
>bypassing resolved. But of course, if you do that then you also lose
>LLMNR, mdns, all local synthetic records, merging of VPN zones and so
>on. 

When I'm speaking the DNS protocol, then I don't mind "losing" LLMNR,
MDNS and synthetic records, which never existed in DNS to begin with.
It would however be good to have the split DNS feature, and I see no
reason why that wouldn't work with DNSsec. Of course, whether a DO query
gets a useful response depends on how good the respective upstream DNS
servers are.

Björn Persson


pgpZ4jxX5uB6m.pgp
Description: OpenPGP digital signatur
___
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

2020-09-28 Thread Björn Persson
Zbigniew Jędrzejewski-Szmek skrev:
>On Mon, Sep 28, 2020 at 01:15:36PM -0400, Stephen John Smoogen wrote:
>> Hey for those of us in the peanuts gallery watching this play out.. could
>> each of you point out which standards and RFC you are complying too. There
>> are a lot of ones and funny enough.. they don't all agree with each other
>> at times.  
>
>https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/
>in this particular case.

That IAB statement isn't itself a standard, but it references several
standards. It even quotes RFC 3397 as saying:

 [2]   Resolve a name that contains any dots by first trying it as an
   FQDN and if that fails, with the local domain name (or
   searchlist if specified) appended.

 [3]   Resolve a name containing no dots by appending with the
   searchlist right away, but once again, no implicit searchlists
   should be used.

The name "dk." contains one dot, while "dk" contains no dots. According
to the quoted rules those two shall be resolved differently. "dk."
shall be treated as a fully qualified domain name. Now people are
saying in this thread that systemd-resolved treats both as local names
and doesn't even try to look them up in DNS. So does systemd-resolved
comply with this standard or not?

Björn Persson


pgpR1LBeVrXuG.pgp
Description: OpenPGP digital signatur
___
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: btrfs / booting alternative OS versions from subvolumes

2020-09-19 Thread Björn Persson
Daniel Pocock wrote:
> All these OS installs would shared some things like /home

That would be likely to break various user programs. Sometimes a
program – for example an email client – changes its internal file
format or directory layout. When the new version sees the old format,
it concludes that it has been upgraded, and automatically converts the
files to the new format. Then you reboot into another OS with an older
version of the program, which doesn't understand the new format.

Björn Persson


pgpa6uCnwWouC.pgp
Description: OpenPGP digital signatur
___
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: F33 update stuck for past 6 days in request for testing->stable

2020-09-12 Thread Björn Persson
Kevin Fenzi wrote:
> We are in Beta freeze. Only packages that fix accepted blocker bugs or
> freeze break exceptions can go stable. 
> 
> https://fedoraproject.org/wiki/Milestone_freezes

Would it be possible for Bodhi to say so, so people don't need to ask
here on the mailing list?

Kevin's wording is perfect. It just needs to be visible in the web
interface, with the words "Beta freeze" as a link.

Björn Persson


pgpfEuTuG6xiz.pgp
Description: OpenPGP digital signatur
___
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: [Test-Announce] Re: Fedora 33 Beta Go/No-Go and Release Readiness meetings

2020-09-11 Thread Björn Persson
John M. Harris Jr wrote:
> On Thursday, September 10, 2020 11:56:25 PM MST alcir...@posteo.net wrote:
> > But systemd in Fedora is built to use 
> > FallbackNTPServers=0.fedora.pool.ntp.org 1.fedora.pool.ntp.org
> > 2.fedora.pool.ntp.org 3.fedora.pool.ntp.org  
> 
> Sounds like a good change, which should be made for DNS as well.

So where is a global pool of volunteer-provided DNS resolvers similar
to pool.ntp.org? I've never heard of one, and I suspect it's not
advisable to do that with DNS.

Björn Persson


pgpOgqC0Qs2k_.pgp
Description: OpenPGP digital signatur
___
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


[EPEL-devel] Re: proposal: EPEL 8 Next

2020-09-09 Thread Björn Persson
Matthew Miller wrote:
> This all leads me to think that actually what we want is not "EPEL Stream"
> but "EPEL for Stream".

That seems to be true.

> (epel-for-stream? epel-4-stream? epel4s? no not that last one for sure.)

Please, no "4"! It looks like a version number.

Björn Persson


pgp5SSPQPuErS.pgp
Description: OpenPGP digital signatur
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org


Re: The Future of the Java Stack (also regarding ELN and RHEL)

2020-09-09 Thread Björn Persson
Guido Aulisi wrote:
> IMHO we could package only the JDK and let the user use Java software 
> directly from upstream.
> Usually upstream means Apache, which is a trusted source, and Java users are 
> smart enough to manage the Java packages.
> I usuali do so when using maven, hadoop, tomcat, etc.
> I think this solution could be valid for any other language, like php, 
> python: packaging only the base language and anything that is not available 
> in executable formats.

And how well does that scale?

As a sysadmin I don't normally need to know what language each program
is written in. I use language-specific tools only on programs I'm
developing, not on programs I merely use. Should I periodically run
cpan to check for Perl program updates, pip to check for Python program
updates, npm to check for Javascript program updates, gem to check for
Ruby program updates, and so on and so forth? And then manually check a
bunch of individual upstream websites for updates to programs that
aren't in those language-specific repositories either? No way! I run
"yum update" and get *all* the updates for my system.

Björn Persson


pgpmHQlIfF1QL.pgp
Description: OpenPGP digital signatur
___
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: What is the real value of Release and %changelog metadata?

2020-08-23 Thread Björn Persson
Pierre-Yves Chibon wrote:
> On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> > Let's stop requiring Release bumps for each build.  And let's put an
> > additional tag into Release, like proposed in [4]:
> > 
> > "Release: 1%{?dist}%{?buildtag}"
> > 
> > ... and let the build-system to put there an artificial (but increasing for
> > subsequent build IDs) value.  
> 
> When looking into rpmautospec this was one of the idea we thought about. There
> are a few downsides to it that made us go in a different direction:
> 
> - Relies on the build system and cannot be emulated locally (without access to
>   it)

Using timestamps for buildtags would work across build systems, relying
only on the clock not being wildly off.

Using Copr build IDs and Koji task IDs, each build system would have
its own series of buildtags. Local Mock and plain RPMbuild could have
their own series too, using timestamps or something else.

The feature that was recently added to Copr generates buildtags that
begin with ".copr". Buildtags from Koji could begin with ".koji". These
prefixes could be chosen so that a build from Koji takes priority over
one from Copr, and a local build takes priority over both of those. I
notice that "local" > "koji" > "copr". How convenient. (A package being
moved from Fedora to Copr would then need a manual release bump, but I
can't think of a reason to do that if there's neither a new version nor
any change to the packaging.)

> - Conflicts wit the minor release bump field of the versioning schema:
>   
> https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/#_more_complex_versioning

I think I see what you mean. If buildtags are purely numeric, then
inserting a small numeric minorbump before the buildtag where the field
was previously empty would cause the new build to compare as less than
the previous one:

$ rpmdev-vercmp 1-1.fc33.98765 1-1.fc33.1.98789
1-1.fc33.98765 > 1-1.fc33.1.98789

If, on the other hand, buildtags begin with a letter and minorbumps are
numeric, then a build with a minorbump would compare as greater:

$ rpmdev-vercmp 1-1.fc33.koji98765 1-1.fc33.1.koji98789
1-1.fc33.koji98765 < 1-1.fc33.1.koji98789

Another option is to have the minorbump field always present, with the
value 0 when not in use. Yet another option is to put the minorbump
after the buildtag. I'd say this is technically manageable, but there
is some risk that packagers would do minorbumps wrong by mistake.

Björn Persson


pgpFWv2VjPrhd.pgp
Description: OpenPGP digital signatur
___
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: What is the real value of Release and %changelog metadata?

2020-08-18 Thread Björn Persson
Richard W.M. Jones wrote:
> On Thu, Aug 13, 2020 at 03:08:50PM +0200, Pavel Raiskup wrote:
> > Let's stop requiring Release bumps for each build.  And let's put an
> > additional tag into Release, like proposed in [4]:
> > 
> > "Release: 1%{?dist}%{?buildtag}"  
> 
> Can I ask why this wouldn't be:
> 
> Release: 1%{?buildtag}%{?dist}
> 
> ?

Putting the buildtag after the disttag makes it possible to change how
the buildtag is generated in a future Fedora release without breaking
upgrade paths.

Björn Persson


pgpVx0tQlAzLT.pgp
Description: OpenPGP digital signatur
___
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: What is the real value of Release and %changelog metadata?

2020-08-16 Thread Björn Persson
Till Maas wrote:
> what about other special cases when using 0.1 for the release to
> indicate pre-releases or git IDs for snapshots. How would  that look
> like with your proposal?

None of that needs to change just because a buildtag is appended.

Whenever the source code changes in any way, one or more of the current
parts of the Version and Release fields should be updated. For a
rebuild, when the source code hasn't changed, the spec wouldn't need to
change either, and only the buildtag would set the rebuilt package
apart from the previous one.

Björn Persson


pgpKgVAI1YTSr.pgp
Description: OpenPGP digital signatur
___
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: What is the real value of Release and %changelog metadata?

2020-08-13 Thread Björn Persson
Pavel Raiskup wrote:
> Questionnaire right at the beginning, so if you tl;dr, you don't miss it:
> 
> https://forms.gle/Jgr13vtRkiUwLb6W6

The questionnaire itself is short, but understanding all the proposals
is considerable work. That's where TL;DR will happen.

> Let's stop requiring Release bumps for each build.  And let's put an
> additional tag into Release, like proposed in [4]:
> 
> "Release: 1%{?dist}%{?buildtag}"
> 
> ... and let the build-system to put there an artificial (but increasing for
> subsequent build IDs) value.

I am of course in favor of this, as I've already suggested it myself.

> Or alternatively, teach the build-system to enhance
> %dist in a similar fashion, as suggested in [5].

That would also work technically, although it would turn the name
"dist" into a misnomer.

>   %changelog
>   * This package doesn't provide changelog metadata, check it online
> https://src.fedoraproject.org/rpms//commits/

To the extent that users read changelogs at all, I think they would be
more interested in the upstream changelog than in the Fedora Git
changelog.

> Side question:  Is it really useful to put "Rebuilt for
> https://fedoraproject.org/wiki/Fedora_XX_Mass_Rebuild; into changelogs?

I don't see any use for those entries. There is already a build
timestamp in the package metadata.

Björn Persson


pgpMsq9P1nJQE.pgp
Description: OpenPGP digital signatur
___
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: Coin4 build failure

2020-08-07 Thread Björn Persson
> You do not have support for any sources of high quality entropy
> enabled. For end user security, that is probably not what you want. Your
> options include: * Linux + glibc >=2.25 (getrandom): HAVE_GETRANDOM, *
> Linux + glibc <2.25 (syscall SYS_getrandom): HAVE_SYSCALL_GETRANDOM, * BSD
> / macOS >=10.7 (arc4random_buf): HAVE_ARC4RANDOM_BUF, * BSD / macOS <10.7
> (arc4random): HAVE_ARC4RANDOM, * libbsd (arc4random_buf):
> HAVE_ARC4RANDOM_BUF + HAVE_LIBBSD, * libbsd (arc4random): HAVE_ARC4RANDOM +
> HAVE_LIBBSD, * Linux / BSD / macOS (/dev/urandom): XML_DEV_URANDOM *
> Windows (RtlGenRandom): _WIN32. If insist on not using any of these,
> bypass this error by defining XML_POOR_ENTROPY; you have been warned.
> If you have reasons to patch this detection code away or need changes
> to the build system, please open a bug. Thank you!

My interpretation is that they want you to choose a source of
randomness by defining one of those macros, so can you get the build
system to pass -DXML_DEV_URANDOM to g++?

Björn Persson


pgpPcZvc6LN8c.pgp
Description: OpenPGP digital signatur
___
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


[EPEL-devel] Re: gcc-gnat

2020-07-15 Thread Björn Persson
Thanks Stephen and Florian for your input. It's now clear that a package
that only adds the "missing pieces" won't work.

Stephen John Smoogen wrote:
> 1. Make a non-default module which contained all the rebuilt binaries
> needed to make gcc-gnat and other tools work (some languages also need
> other utilities rebuilt to work).
> 2. Make an SCL which contains all these.
> 3. Make a set of rpms which installed gcc in all the same places
> as gcc but didn't collide

The module option seems like it would be easiest to use for the users,
and would also avoid the risk that one program might invoke the wrong
build of another program.

Björn Persson


pgpyLtaHSqWWa.pgp
Description: OpenPGP digital signatur
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org


[EPEL-devel] Re: gcc-gnat

2020-07-14 Thread Björn Persson
Erick Wittman wrote:
> I am using CentOS 8 and am using various packages in the EPEL
> repository. I am interested in seeing gcc-gnat added to EPEL.

I would also like to have gcc-gnat in CentOS 8. I maintain some Ada
packages in Fedora and EPEL 7 that I wish I could add to EPEL 8.

In Fedora and earlier versions of RHEL/CentOS, gcc-gnat is a subpackage
of gcc. Adding it to EPEL would make it a separate package. I'm not
sure what complications might arise from that.

So far I haven't had time to even try. I suspect I won't be able to do
it alone, but it might be doable if we could assemble a team of
interested maintainers.

Björn Persson


pgpGcJuYYL9Aq.pgp
Description: OpenPGP digital signatur
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org


Re: Can we do away with release and changelog bumping?

2020-07-06 Thread Björn Persson
Adam Saleh wrote:
> Piere (a.k.a Pingou), Nils and me worked on Rpmautospec [1] to solve this
> problem few months ago.
> It is a koji plugin as well as CLI tool that makes bumping the release
> field and generating changelog problem of Koji,
> instead of package-maintainer. Currently it sits deployed in staging koji,
> so you can give it a test-drive :-)

What will the release value be when a package that uses autorel is built
with fedpkg local?

Or fedpkg mockbuild?

Björn Persson


pgpbSFrl37n3U.pgp
Description: OpenPGP digital signatur
___
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: Can we do away with release and changelog bumping?

2020-07-06 Thread Björn Persson
Florian Weimer wrote:
> * Björn Persson:
> 
> > The macro could be defined like this for example:
> >
> >   %buildtag .%(date +%%s)  
> 
> Using time for synchronization is always a bit iffy.

Well, if somebody manages to build a package twice within a second,
using two different versions of a compiler ... then they still won't be
any worse off than they are today. Koji should still not allow it.

> > It would be used in each spec like this:
> >
> >   Release: 1%{?dist}%{?buildtag}  
> 
> We could put the Koji task ID directly into the %dist tag.  We know that
> this works in principle.  If we are worried that the number gets too
> large, we could subtract the current task ID at the time the fcNN part
> of the %dist tag changes.

That could also work. Locally rebuilt packages would of course lack the
task ID, so they would compare as less than the official package. Is
that desirable? It could work as an incentive for the user to add some
local tag to the release value, making it clearer that the package has
been modified locally.

Or would we want to modify the disttag so that locally rebuilt packages
would compare as greater than the corresponding official package? Then
Yum would replace the official package with the rebuilt one, but would
still install an official update with a greater release number.

Björn Persson


pgpTBEyG2fROW.pgp
Description: OpenPGP digital signatur
___
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: Can we do away with release and changelog bumping?

2020-07-05 Thread Björn Persson
Nicolas Mailhot via devel wrote:
> Le dimanche 05 juillet 2020 à 17:46 +0200, Björn Persson a écrit :
> > It seems that several problems would just disappear if a rebuild
> > would generate a unique package ID without a Git commit.  
> 
> That’s exacly what the change does.

No it's not. Your key/value file must be updated in Git. Otherwise it
won't remember previous release bumps. You seem to want to do the commit
after building instead of before, but it's still a commit to Git that
changes only the release number and the changelog. My idea is a way to
*not* do that commit, neither before nor after building.

Björn Persson


pgp_iMlQVE_gO.pgp
Description: OpenPGP digital signatur
___
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


Can we do away with release and changelog bumping? (was: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal)

2020-07-05 Thread Björn Persson
Nicolas Mailhot via devel wrote:
> So if you want to push Fedora release logic to its ultimate conclusion,
> the thing that should be in charge of committing the new
> release/changelog build state to package history in git is bodhi, not
> koji.

Why do build events need to be recorded in the Git history in the first
place? A version control system is supposed to track changes to the
source code. A rebuild that doesn't change any sources, patches,
scriptlets or metadata shouldn't need to change anything in Git.

As far as I can tell, this happens only because Koji refuses to build a
NEVR that has been built before, so a rebuild requires a new release
number, which requires an RPM changelog entry, and both of those are
defined in the spec, which is stored in Git.

So why is NEVR required to change when nothing in the package source
has changed? Apparently because *other* packages are likely to have
changed: new versions of libraries, compiler et cetera causing
differences in the generated code. That's the usual reason for rebuilds
after all. But if one takes a source package and rebuilds it locally,
then one won't have the same version of every other package, so one
gets another binary package with the same NEVR but probably different
binary code.

It seems that several problems would just disappear if a rebuild would
generate a unique package ID without a Git commit. Instead of a lot of
complex tooling to automate release and changelog bumping, I would like
to see the need for release and changelog bumping go away.

Here's an idea: We could mandate that Release must expand a macro
called buildtag. This macro would have a new value every time,
monotonically increasing. A timestamp seems easiest, but that should be
an implementation detail that could be changed without breaking things.

The macro could be defined like this for example:

  %buildtag .%(date +%%s)

It would be used in each spec like this:

  Release: 1%{?dist}%{?buildtag}

Putting the buildtag after the disttag makes it possible to change how
the buildtag is generated in a future Fedora release without breaking
upgrade paths.

(The build time is already stored in packages, and could theoretically
be used to tell builds apart, but that would require changes to lots of
tools I guess.)

Mass rebuilds would no longer make any Git commits. They would just
take the latest version and submit it for building. The release number
would remain as a downstream version number. Packagers would update the
release number when they make actual changes to the package. When one
wants a specific version of a package, one would look at the version
and release numbers, ignoring the buildtag. The buildtag would
distinguish between different builds of the same version-release.

What flaws can you all find in this idea?

Björn Persson


pgpIGk2i3K6iH.pgp
Description: OpenPGP digital signatur
___
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: use of 'date' in rpm .spec %define concats add'l str chars?

2020-07-03 Thread Björn Persson
PGNet Dev wrote:
>   %define _build_timestamp %( date +%Y%m%d_%H%M%S )

Percent signs that are not to be interpreted as RPM syntax need to be
doubled. Write this as:

  %define _build_timestamp %(date +%%Y%%m%%d_%%H%%M%%S)

Björn Persson


pgpSR1gksDcHm.pgp
Description: OpenPGP digital signatur
___
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: Is allowed in certain cases to override default Fedora compiler flags?

2020-07-02 Thread Björn Persson
Sergio Belkin wrote:
> Thanks everyone, I guess the same thing goes for:
> 
> warning: ignoring return value of 'ssize_t write(int, const void*, size_t)'
> declared with attribute 'warn_unused_result'
> 
> (The line in the source code  is if(upLogPerror) ::write(2,logbuf,n); \  )
> 
> doesn't it?

Ignoring the result of write is usually a serious bug. However, that
line looks like it writes a log message to the standard error stream,
and in that specific case there might not be anything meaningful the
program can do if write fails, if it doesn't want to terminate with an
error status. Logging an error message about how logging failed could
easily lead to infinite recursion.

So depending on what other error reporting mechanisms are available to
the program, it may be reasonable to ignore the function result in this
case, but it should be done by tweaking the code to silence the
compiler warning for that call only. Disabling -Wunused-result for the
whole program is not a good idea.

Björn Persson


pgpmAzjiNZ85n.pgp
Description: OpenPGP digital signatur
___
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: Is allowed in certain cases to override default Fedora compiler flags?

2020-07-02 Thread Björn Persson
Zbigniew Jędrzejewski-Szmek wrote:
> On Wed, Jul 01, 2020 at 05:47:51PM -0300, Sergio Belkin wrote:
> > So the question is: in this case I can override the Fedora compiler flags?  
> 
> Other people replied with suggestions how to make the code better, but
> let me also answer this question directly:
> 
> yes you can, the guidelines say:
> 
> >  Adding to and overriding or filtering parts of these flags is
> >  permitted if there’s a good reason to do so; the rationale for
> >  doing so must be documented in the specfile.  

Note the words "good reason". As I understand it, Sergio's question is
whether this case is a good reason. In my opinion, incorrect use of
snprintf and write are bad reasons for overriding the compiler flags.
It's better to fix the actual problem than to silence the alarm.

Björn Persson


pgpf9I2zAvuwr.pgp
Description: OpenPGP digital signatur
___
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: Is allowed in certain cases to override default Fedora compiler flags?

2020-07-02 Thread Björn Persson
Sergio Belkin wrote:
> Regarding to " format not a string literal and no format arguments
> [-Werror=format-security]" message.
> Afaik instructions of kind printf(format,var1,var2,...) always be fail,
> since it can't verify in compile time  that the format includes the number
> of variables that appears later.

GCC does exactly that. It has special knowledge of the printf family of
functions and verifies that the arguments match the format.

If you define a function that takes printf-like parameters, then you
should include an attribute like this:

void log(foo f, const char *format, ...) __attribute__((format(printf, 2, 3)));

Then GCC will verify that the arguments match the format in calls to
your function too.

> If the developer does not use entered formats by the user, the exploit
> disappear, doesn't it?

Is it guaranteed that the string can never under any circumstances ever
possibly contain a percent sign? If so, it's probably safe – in the
current version of the program, but who knows what changes might be
made in the distant future?

Tell upstream to just add "%s" as the format string and be done with
it. If they find that burdensome, then that's because they made a bad
choice of programming language.

Björn Persson


pgp7dztvU6yd2.pgp
Description: OpenPGP digital signatur
___
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-packaging] Re: RPM-level auto release and changelog bumping - Fedora 33 System-Wide Change proposal

2020-07-02 Thread Björn Persson
Nicolas Mailhot wrote:
> The same process that commits a new state of the changelog file in 
> sources,
> commits the date that was written in the changelog in a separate key = 
> value
> file (with the components of the build evr, the last packager id, etc).

Do you mean that the key/value file will be committed to Git from inside
Koji? Do the Koji builders have write access to Git?

> commit the new build event timestamp in 
> the detached changelog file at %build time

%build is executed once per arch, on different builders, so which
builder's timestamp gets committed to Git?

Björn Persson


pgpGqB7XyDrRt.pgp
Description: OpenPGP digital signatur
___
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: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Björn Persson
Jóhann B. Guðmundsson wrote:
> More user friendly than Grub ( has lilo like interface easier to change 
> kernel entry, which goes nicely with the default editor change )

This made me go "What?!". I used Lilo back in the day. Its user
interface was nothing but a prompt. You had to know what to type or
you'd be stuck.

Information for others like me who haven't seen Lilo since Grub came
along: Apparently development of Lilo continued until just five years
ago, and it grew a menu at some point. I guess that menu is the image
of user-friendliness that Johann was trying to invoke.

Björn Persson


pgpD3F8m6oPGh.pgp
Description: OpenPGP digital signatur
___
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: The future of legacy BIOS support in Fedora.

2020-07-01 Thread Björn Persson
Jóhann B. Guðmundsson wrote:
> Such proposal would never be about stop supporting older hardware that's 
> just a misconception people are getting

When you write "stop supporting booting in legacy bios mode and move to
uefi only supported boot", then you shouldn't be too surprised if people
believe that you're proposing to stop supporting BIOS and support only
UEFI.

Björn Persson


pgpifrbSgXICa.pgp
Description: OpenPGP digital signatur
___
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: Use %make_build and %make_install macros

2020-06-22 Thread Björn Persson
Tom Stellard wrote:
> On 06/22/2020 10:00 AM, Björn Persson wrote:
> > Tom Stellard wrote:  
> >> The reason I put in the proposal that all make invocations would be 
> >> updated,
> >> is because this is easier to script and it would be hard for someone who
> >> doesn't know the package to make the call about which invocations don't
> >> need to use parallel make.  
> > 
> > It's often tempting to do the easy thing instead of the right thing.
> 
> What do you think would be the right thing to do in this case?

To study each make invocation, determine whether it's parallelizable
and judge whether future build flags will be appropriate – which is
obviously much more work for the person pushing the change, but avoids
making work for package maintainers.

Björn Persson


pgpE4hqIKgNns.pgp
Description: OpenPGP digital signatur
___
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


  1   2   3   4   5   6   >