Re: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

[Sam Varshavchik]

Kevin Kofler via devel writes:


You make a good point there. The thing is, GNOME tries really hard to design
for new users, whom they define as a user who has never before used a
computer.


So, someone who never used at a computer before sits down in front of a new,  
empty, Gnome desktop, and it is expected that they'll take to it like a fish  
takes to water?


I doubt that very much.

Besides, there's a fatal flaw in this hypothetical scenario.

No such person could possibly exist. A completely new to computers user is  
not going to be sitting down in front of a new desktop, all by themselves.  
Without anyone else in the picture.


This is not going to happen.

There's going to be someone else, sitting next to them, who will be teaching  
the new user how to use a computer. And that someone will /also/ be familiar  
with traditional desktop concepts and paradigms. They, like the new user,  
will also expect to have a traditional desktop in front of them, that works  
like a traditional desktop.


And that was the fatal flaw in the grand experiment called "Gnome 3".



pgpI4t7CKKvbD.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Sam Varshavchik]

Christoph Erhardt writes:


I strongly oppose this suggestion. While it would have prevented this
particular backdoor as a side-effect, the primary effect of going without  
unit

tests would be an outsize hole in Fedora's QA.


There have been several suggestions here for ways that this specific attempt  
from succeeding.


Any one of them will be very useful as long as it is guaranteed that all  
backdoor/supply chain attacks in the future are attempted in the exact same  
technical way.




pgpWXQfPOVO6k.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Three steps we could take to make supply chain attacks a bit harder

[Sam Varshavchik]

Tim Landscheidt writes:


A major factor seems to have been the discrepancy between
"the source code" at GitHub & Co. that was probably
scrutinized by many eyes and the shipped, but different
artifact.  So one step (as a inter-distribution effort)
could be to continuously automatically compare shipped
artifacts with their "make dist" equivalents and publishing
the results.


There are several versions of autoconf, automake, and libtool in wide use.

There are also many libraries that ship autotools macros for inclusion in  
code that builds against those libraries. Those macros don't change very  
often, but they do change.


You will need to match the version for everything in the build environment  
in order to meaningfully compare autotools-generated shellcode.




pgp6JJOFBLwYC.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Optimized Binaries for the AMD64 Architecture (System-Wide)

[Sam Varshavchik]

Oron Peled writes:

• I.e: a developer that need cross-compilation, install the wanted  
toolchain(s) and all library packages are immediately available from standard  
repositories.


I guess Fedora people that work on ARM/ARM64/RISC-V would love such a  
support.


There are a number deb packaging policies that rpm would be wise to adopt.

A package's shared libraries get rolled into a separate   
package right off the bat. An ABI break and a transition where both the new  
and the old libraries must coexist becomes a nothing-burger. The updated  
package's libraries go into a subpackage with, effectively, a new name that  
does not cause the older library's uninstallation. There is no need to  
create a compat package. It's the same package, from the previous version.




pgphaQFO76cNT.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild core dumps

[Sam Varshavchik]

Florian Weimer writes:


* Sam Varshavchik:

> Stephen Smoogen writes:
>
>>https://github.com/rpm-software-management/rpm/issues/
>>2826>https://github.com/rpm-software-management/rpm/issues/2826
>>
>>
>> And thanks for opening a bug. I will watch to see what happens. 
>
> I'm genuinely curious. Am I really the only one seeing this? The bug
> seems fairly clear cut to me. What the heck.

I suspect most of us package only files from one user, so the cache
never needs evicting?


You know, I think you're right. You need to put files into rpms that have  
different user and group ownership. Nearly all packages likely %defattr away  
all files to the same user and group id the race condition never gets  
triggered.


The race condition occurs when the next file that gets added to the rpm is  
specified to have a different user or group ownership from the previous file.




pgpehJrVvEXHx.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild core dumps

[Sam Varshavchik]

Stephen Smoogen writes:


   https://github.com/rpm-software-management/rpm/issues/
   2826>https://github.com/rpm-software-management/rpm/issues/2826


And thanks for opening a bug. I will watch to see what happens. 


I'm genuinely curious. Am I really the only one seeing this? The bug seems  
fairly clear cut to me. What the heck.




pgp3PQIGEzN6H.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild core dumps

[Sam Varshavchik]

Stephen Smoogen writes:


I am trying to figure out the logic of this section:


```

    static char * lastUname = NULL; // So lastUname is NULL
    static uid_t lastUid;

    if (!thisUname) {
        lastUname = rfree(lastUname); // lastUname should still be NULL and  
we are freeing NULL and setting itself back to NULL.

        return -1;

```



I expect this is where I am not understanding something basic in C from too  
many years in non-pointer land. I looked at the change of these lines and  
they date back to this commit. 


This is a fairly common kind of simple caching to avoid expensive  
username/userid and groupname/groupid lookups by caching the last one. This  
code is expecting that it will be called, repeatedly, to look up the same  
user/group, so it caches the results of the last lookup, and returns it.  
Most of the files in a binary rpm would typically have the same uid gid  
owner, so these functions are expected to be called with the same values  
each time.


Which now get cached in static variables. This worked great while everything  
was single-threaded.


Now, if you have two execution threads going step by step right here, and  
both of them passed in a null pointer, both of them will run this, and both  
of them will `free` the same pointer. Fail.


This `static` usage pattern is inherently thread unsafe.

The entries for __thread I found come in around 2019. Did you have a bugzilla  
or a report on https://github.com/rpm-software- 
management/rpm/>https://github.com/rpm-software-management/rpm/ which I can  
add anything I find?





and most date back from 2013. --


https://github.com/rpm-software-management/rpm/issues/2826




pgpRtx7rW1maN.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild core dumps

[Sam Varshavchik]

Stephen Smoogen writes:



I am guessing the problem is really with the free(lastUname) since the rfree


Yes. Multiple execution threads will reach lastUname and try to free the  
same pointer. glibc rightfully complains about the double-free.


isn't referred to (but not sure if an optimization would have removed it. The  
comment before this code mentions that this is a hack to try and get things  
done.. probably from long long ago when rpm was single threaded.


The problem is in all of these functions. It's the same problem with all of  
them. Here's rpmugUname(), for example. You have two execution threads  
traversing that nest of "if" statements and all of them winding up here:


   } else {
   char *uname = NULL;

   if (lookup_str(pwfile(), uid, 2, 0, ))
   return NULL;

   lastUid = uid;
   free(lastUname);

And now both execution threads will try to free() the same pointer.

The next statement resets lastUname to the newly-allocated uname, but it's  
too late. If the code that executes in parallel calls rpmugUname, then just  
say good night.


All of the static variables in all of the functions here must have a mutex  
wrapped around them.


Or declared with a __thread attribute.

The window of vulnerability is very tiny. But I have 32 cores and have 32  
execution threads churning. They have about a 5% chance of hitting the  
double-free on every build. Worse, I can see how this race condition may not  
result in a crash but produce a corrupted rpm.




pgpp7iby8QrFx.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild core dumps

[Sam Varshavchik]

Sam Varshavchik writes:



Looking at a diff between the 4.19.0 an 4.19.1 tags, a call to rpmfiStat()  
was added to fill_archive_entry(). The backtrace above shows the execution  
finding its way from rpmfiStat() into very-much-thread-unsafe code in rpmug.c


That code is used only by rpm2archive, though.

But the backtrace does show an execution path from packageBinaries into  
rpmug.c.


I wonder what happens if someone were to try to rebuild texlive, and all of  
its umpteen packages. That should thoroughly excersize the problematic code…




pgpSGpzBw4aNy.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild core dumps

[Sam Varshavchik]

Stephen Smoogen writes:


                   #1  0x7f05dd8588ee raise (libc.so.6 + 0x3e8ee)
                   #2  0x7f05dd8408ff abort (libc.so.6 + 0x268ff)
                   #3  0x7f05dd8417d0 __libc_message.cold (libc.so.6 +
   0x277d0)
                   #4  0x7f05dd8b47a5 malloc_printerr (libc.so.6 +
   0x9a7a5)
                   #5  0x7f05dd8b6a3a _int_free (libc.so.6 + 0x9ca3a)
                   #6  0x7f05dd8b93de free (libc.so.6 + 0x9f3de)
                   #7  0x7f05dda984ec rpmugUid (librpm.so.10 + 0x584ec)
                   #8  0x7f05dda84255 rpmfilesStat (librpm.so.10 +
   0x44255)
                   #9  0x7f05dda8438f rpmfiStat (librpm.so.10 + 0x4438f)
                   #10 0x7f05dda8 rpmfiArchiveWriteHeader (librpm.so.
   10 + 0x4)
                   #11 0x7f05dda871c9 iterWriteArchiveNext (librpm.so.10
   + 0x471c9)


Thanks. I was wondering if it was dnf/rpm on the system or dnf/rpm in the  
chroot but it sounds like something changed between 4.19.0.1 (what I had on  
my system since September?)  and 4.19.1 ( December)




Looking at a diff between the 4.19.0 an 4.19.1 tags, a call to rpmfiStat()  
was added to fill_archive_entry(). The backtrace above shows the execution  
finding its way from rpmfiStat() into very-much-thread-unsafe code in rpmug.c


Further up the backtrace is packageBinaries() which, according to the  
backtrace, is being multithreaded via OMP. Looking at the core dump, I see a  
bunch of execution threads running packageBinaries().


I'm confident that this is the breakage. 4.19.1 needs to be fixed ASAP.

My humble suggestion for the simplest fix is to slap a __thread on all those  
static variables in rpmug.c. Or, perhaps, throw a mutex around them so that  
all execution thread share that micro-optimization those static variables  
are used for…


Hopefully that's the only thing that's thread unsafe in there…



pgpUdgoKdRnr2.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: rpmbuild core dumps

[Sam Varshavchik]

Stephen Smoogen writes:

»My apologies for bad quoting.. email from phone. What version of rpm build  
is used and what are some packages which are rebuilt that show this issue.  
This may be needed if the core dump is due to something else in the  
environment like memory limits etc 


It's 4.19.1 on FC39, and it's packages that I'm working on. It's glibc  
complaining about a double-free, and not any resource limits. I can get a  
backtrace out of it:


   #1  0x7f05dd8588ee raise (libc.so.6 + 0x3e8ee)
   #2  0x7f05dd8408ff abort (libc.so.6 + 0x268ff)
   #3  0x7f05dd8417d0 __libc_message.cold (libc.so.6 + 0x277d0)
   #4  0x7f05dd8b47a5 malloc_printerr (libc.so.6 + 0x9a7a5)
   #5  0x7f05dd8b6a3a _int_free (libc.so.6 + 0x9ca3a)
   #6  0x7f05dd8b93de free (libc.so.6 + 0x9f3de)
   #7  0x7f05dda984ec rpmugUid (librpm.so.10 + 0x584ec)
   #8  0x7f05dda84255 rpmfilesStat (librpm.so.10 + 0x44255)
   #9  0x7f05dda8438f rpmfiStat (librpm.so.10 + 0x4438f)
   #10 0x7f05dda8 rpmfiArchiveWriteHeader (librpm.so.10 + 
0x4)
   #11 0x7f05dda871c9 iterWriteArchiveNext (librpm.so.10 + 
0x471c9)

I am looking at this core dump. I see 32 active execution threads at the  
time this whole thing went kaput, and all the code in rpmug.c is definitely  
not thread safe. I did not look very hard, I don't know if there are mutexes  
higher up the call chain, but the overall behavior – occasional core dumps  
-- is indicative of thread races.





pgpmoev3mIsCL.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)

[Sam Varshavchik]

Kevin Kofler via devel writes:


Sam Varshavchik wrote:
> The ostensible reason for this is that you cannot be tracked by your fixed
> MAC across different APs.

But different APs will typically be operated by different people, who have
no access to each other's MAC address logs anyway. So what is the point of
sending them a different made-up MAC?


I'm not advocating for it. I also think this is dumb. I'm just the  
messenger, this is just the argument for that.


The threat vector is different APs that are covertly managed by the same  
entity. Geographically discrete APs that can be used to track the target  
using the target's fixed MAC address.


Many SSIDs are well known, McDonals, etc… Presuming that the target's device  
knows the AP and auto-connects to the SSID a threat actor can covertly track  
the target by setting up rogue APs, in different geographic areas.



> Yes, your visits to the same AP can still be tracked by that AP, but
> that's as far as it goes. And the reason for using the same MAC with the
> same AP is to still make it possible to do MAC address filtering.

Sure, I understand that. But it is inherently impossible to allow MAC
address filtering while blocking MAC address tracking. They are basically
two use cases of the same thing.


Not if the MAC is randomized per AP. The randomized MAC will remain fixed  
for that AP only, hence MAC filtering is still possible.




pgprJ7caLS3Ao.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

rpmbuild core dumps

[Sam Varshavchik]

It seems that rpmbuild dumps core at the end of the build process, every  
once in a while. Typical:


Wrote: 
/__w/courier-libs/courier-libs/courier-authlib/rpm/RPMS/x86_64/courier-authlib-userdb-debuginfo-0.72.0.20231223-101.fc39.x86_64.rpm
Wrote: 
/__w/courier-libs/courier-libs/courier-authlib/rpm/RPMS/x86_64/courier-authlib-devel-0.72.0.20231223-101.fc39.x86_64.rpm
double free or corruption (fasttop)
make[1]: *** [Makefile:2447: dorpm] Aborted (core dumped)
make[1]: Leaving directory '/__w/courier-libs/courier-libs/courier-authlib'
make: *** [Makefile:2439: rpm-build] Error 2

Just trying again, with the same build, typically succeeds. In my estimate  
it dumps core about 5% of the time, randomly.


I can rule out a hardware issue on my side, because this just happened in a  
github workflow container:


https://github.com/svarshavchik/courier-libs/actions/runs/7315972215/job/19930137170

You'll probably need to be signed into github see the log, but that's  
basically it.


I can't find anything relevant in Bugzilla, is anyone else seeing this, too?



pgpTpfftu09M9.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)

[Sam Varshavchik]

Kevin Kofler via devel writes:


Sam Varshavchik wrote:

> Christopher Klooz writes:
>
>> Btw, does anyone know if this (in the practically-same manner) is really
>> already introduced in Windows, Mac, Android by default? Globally? This
>
> Most recent Android phones, and iPhones do this by default.
>
> What they do is pin each randomized MAC address per AP. They're not
> randomizing MACs for each connect, but basically generate a randomized MAC
> for each AP known to the phone.

What is this actually good for? Any AP you connect to can still track you
this way, and anything further uplink should not get your MAC address to
begin with anyway (only your IP address).


The ostensible reason for this is that you cannot be tracked by your fixed  
MAC across different APs. Yes, your visits to the same AP can still be  
tracked by that AP, but that's as far as it goes. And the reason for using  
the same MAC with the same AP is to still make it possible to do MAC address  
filtering.


pgpsjgtOJxrI2.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Wifi MAC Randomization (System Wide)

[Sam Varshavchik]

Christopher Klooz writes:

Btw, does anyone know if this (in the practically-same manner) is really  
already introduced in Windows, Mac, Android by default? Globally? This


Most recent Android phones, and iPhones do this by default.

What they do is pin each randomized MAC address per AP. They're not  
randomizing MACs for each connect, but basically generate a randomized MAC  
for each AP known to the phone.




pgp8dkqPhfwm0.pgp
Description: PGP signature
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Re: shotcut compilation fails with "error: ‘hasPro’ was not declared in this scope"

[Sam Varshavchik]

Martin Gansser writes:

I have copied the virtual machine from a Windows computer to my Fedora 38  
computer and shotcut can no longer be compiled here, but it can on the  
Windows computer.
Do I have to repair the file system on the Linux computer or do anything  
else?


You snipped out the relevant details of the filesystem being corrupted due  
to a likely RAM error.


The bad RAM could be on either machine. If the bad RAM was on your Windows  
computer, you copied it off unstable hardware, and your entire VM's  
integrity has been compromised in some unknown way.


You might try making another copy of the VM, and if you don't end up with  
identical corruption it likely indicates that the bad RAM  corrupted the  
data in transit, and the original VM image is /probably/ ok. However until  
you isolate and replace the faulty RAM you can't really do anything with  
some guarantee of stability. Only after identifying and replacing the faulty  
RAM you can then make another copy of the VM with some level of confidence.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: OpenCOLLADA need a little c++ help

[Sam Varshavchik]

Richard Shaw writes:

error: possibly dangling reference to a temporary [-Werror=dangling- 
reference]
  315 |                 const auto & parents =  
dae.root().selectNodes("//*[@sid]/..");


This is a complaint about a potential problem that might, just might be  
true. It can't be determined without inspecting the contents of the  
function. The diagnostic does not, and just assumes the worst.


TLDR: if a function call parameter is a const ref, and gets initialized from  
a prvalue, and the function returns the same const ref type, gcc will whine  
about a potential dangling reference being used, on the theory that the  
function might be returning the same const ref that's getting passed into  
it, but the temporary prvalue gets destroyed at the end of the statement.


That's literally what this error means.

The discussion in gcc's bug tracker discovered that gcc will emit this  
warning solely based on the function's signature and without considering the  
contents of the function. It just assumes that this might be a problem here  
and helpfully raises its hand.


The quickest solution is just add a pragma to shut it up.


The code in question[2] is:
  // InstanceWithExtra and other  with "url" attribute
const auto & instances = root().selectNodes(


Find where selectNodes() is defined. Add

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"

before the definition, and

#pragma GCC diagnostic pop

after it.

This all presumes that this is a false positive, which I'll estimate will be  
the case more often than not.




There's a 2nd instance of the error but I think I can fix it once the path  
forward on the first is addressed.


What are the odds that the 2nd occurence of this is an actual problem?



pgpO4A0ian4qz.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Deprecation of the aspell package

[Sam Varshavchik]

Mattia Verga via devel writes:


I'd also like to raise attention to what I think is a misleading Change
Summary:

> Deprecating aspell package because it is no longer
> Required/Buildrequired by any package in Fedora.
This is clearly not true, as the change is about migrating package to
another spellchecker.


I have one package in Fedora. It uses aspell's C++ API.

Hunspell does not have a functionally-equivalent C++ API. It has a C++ API  
of its own, but it's targeted at applications that come with their own  
language dictionaries. Its C++ API is, basically, a lookup function against  
a dictionary file that the application also supplies, it does not have a C++  
API that offers a convenient way for applications to run a spell check  
against the system's default dictionary. The way for an application to do it  
is to have it run hunspell itself separately, and talk to it via pipes.  
Hopefully, it's easy for the application to do that without leaking other  
file descriptors.


I'll have to code that, which I'll do, but I don't know how many other  
applications currently rely on aspell's C++ API, and whether their upstreams  
are also willing to update.




pgpSbgVnsdHrA.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Deprecation of the aspell package

[Sam Varshavchik]

Lukas Javorsky writes:


Hi,


I would like to announce the Fedora change for the deprecation of the aspell  
package [1].



This package has a dead upstream and has been obsoleted (in most occurrences)  
by the hunspell package [2].


http://aspell.net/ does not seem to be dead to me.

This is a spell checker, after all. This is not something I'd expect to see  
monthly updates for. Languages evolve over the course of centuries. It's  
true that there's a small number of self-appointed authorities that put on  
an annual pomp-and-circumstances affair announcing this year's addition to  
King's English. But I'll be impressed if anyone can recall what last year's  
additions were.





pgpe7I9lip7mk.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F39 proposal: Man-pages-ru Retirement (Self-Contained Change proposal)

[Sam Varshavchik]

Leslie Satenstein via devel writes:

As a developer, and I believe, other developers who use C, C++, Rust,  etc, I  
would like to do a man  "whatever.h" to optain a list of the defines, and  
from that list, I would choose to select  the entry for which I need more  
information.



Please give some thought to the programmer sitting at a terminal and who is  
debugging someone else's code.  


Your best chances of making this happen is by directing this to the man  
pages' maintainer. Fedora simply repackages what the man pages maintainer  
puts out.


You can subscribe to the  mailing list, and ask  
this over there.





pgpfJ61blnsSi.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: It’s time to transform the Fedora devel list into something new

[Sam Varshavchik]

Matthew Miller writes:


I don't think this is _really_ a "there are two kinds of people in the
world..." situation. Of course there are some people who have preferences
(strong or weak) for one or the other, and completely legitimate pros and
cons to each. But I don't want to "trade" anyone. I'd like to bring everyone
along.


I reread the thread-starter. I did not get that impression. What I read was:  
we'd like to replace the mailing list with discourse. That's it.


There was some mention of discourse's mail integration, but it was clearly  
"mark the checkbox" type of thing.



> I have seen this
> done multiple times over the years, tried to follow a few times, and
> always dropped off fairly rapidly.  I'm solidly in the "email list
> users" group.

Is there anything which could be different this time which would make it
better for you?


I do not believe that any web-based discussion forum would ever be  
comparable to a mailing list, The two environments are worlds apart, and  
irreconcilable, that's simply the way it is. They work in fundamentally  
different ways. I typed and deleted about two paragraphs' worth of my  
explanations why web-based forums are not a replacement for mailing list, I  
changed my mind and concluded that this kind of advocacy won't matter much.  
In the end, whatever happens, happens. The chips will fall where they may.





pgp2iGznVzZc3.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

[Sam Varshavchik]

Florian Weimer writes:


After installing redhat-rpm-config, this works in bash and similar
shells:

$ eval `rpm --eval %set_build_flags`

Maybe we can make it more clear in buildflags.md that this macro is a
shell script fragment?


I find it more convenient to generate parameters for an autoconf-generated  
configure script. I do not need to always use the same build flags as rpm.  
Sometimes you want to build without optimizations, for debugging purposes.


What I do is

./configure `rpmflags`

with "rpmflags" being this script:

#! /bin/bash

echo -n "CXXFLAGS='"
rpm -E '%build_cxxflags' | tr -d '\012'
echo -n "' CFLAGS='"
rpm -E '%build_cflags' | sed 's/ *$//' | tr -d '\012'
echo -n "' LDFLAGS='"
rpm -E '%build_ldflags' | sed 's/ *$//' | tr -d '\012'
echo "'"

I suppose I can turn this inside-out, and change this to use  
%set_build_flags and directly run configure.




pgpb1WTkcDfaO.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Is there convenient way to setup Fedora compilation flags outside of the RPM build?

[Sam Varshavchik]

Vitaly Zaitsev via devel writes:


On 23/12/2022 19:21, Vít Ondruch wrote:
Working with upstream on one issue [1], it seems that the culprit is in the  
Fedora compiler options. Is there some convenient way to set them up?


rpm -E %optflags


rpm -E '%__global_ldflags'

is also needed for LDFLAGS.



pgpjBHXq8wZxo.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Karma for OpenSSL needed

[Sam Varshavchik]

Otto Liljalaakso writes:


Kevin Fenzi kirjoitti 2.11.2022 klo 20.33:

So, I suppose the web interface could offer signed copies if they exist,
but might be confusing if you don't know what the various keys short
hash is. Feel free to file a RFE for koji folks: https://pagure.io/koji


I personally will not, because I have been happily downloading the unsigned  
builds from Koji for testing, thus I cannot really present the case.
But perhaps somebody who would prefer, or insists on, using only signed  
builds wants to?


Given the package URLs are https:// URLs to the fedoraproject.org domain,  
their downloads are effectively signed by fedoraproject.org's SSL  
certificate, which is comparably cryptographically strong as PGP-signed RPMs.


Without having any direct knowledge of the process that PGP-signs the built  
RPMs, I suppose that it's theoretically possible for fedoraproject.org's web  
server to be compromised, which would allow for distribution of compromised  
RPMs, without compromising the PGP-signing infrastructure. But, in  
exceptional situations like the current one, everyone can weigh all the risk  
factors and make an intelligent decision by themselves.




pgp7nqtHC98ST.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Request to change default /etc/resolv.conf symlink

[Sam Varshavchik]

Petr Menšík writes:

If systemd-resolved ever becomes capable as a good DNS cache, we can return  
it back to domain port. I don't think it is ready for that.


Search the archives of the users list for systemd-resolved complaints. I've  
done my share. Perhaps a bunch of them coming from @redhat.com will result  
in some changes, but I doubt it.




pgpMpvbeZ4m5q.pgp
Description: PGP signature
___
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 mock rebuild failure: cannot open linker script file

[Sam Varshavchik]

Zbigniew Jędrzejewski-Szmek writes:


The issue is that in %prep, %buildsubdir is not defined, so the definition
of %_package_note_file, which uses %buildsubdir, has a different value than
in %build and later. Generally the best solution is to move the step that
tries to make use of the package notes file in %prep to %build.
But looking at https://src.fedoraproject.org/rpms/courier- 
unicode/blob/rawhide/f/courier-unicode.spec,


I see that in this one, %configure gets invoked from %build.


I don't see anything in %prep that'd cause an issue. Can you post the
spec file that is causing problems?


But in mine's %configure gets invoked in %prep instead:

https://github.com/svarshavchik/courier-libs/blob/master/unicode/courier- 
unicode.spec.in


I guess I'll move this one to %build as well. I tried searching for some  
current documentation, and all the examples I found also invoked %configure  
from %build.


My recollection was that early rpm packaging documentation was otherwise, in  
the context of using --short-circuit. That is, the tutorials were: get the  
configure options right, then use -bb --short-circuit to get your make to  
succeed, you've already taken care of ./configure in the %setup step.





pgpspm0nFY1Hk.pgp
Description: PGP signature
___
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

F36 mock rebuild failure: cannot open linker script file

[Sam Varshavchik]

I'm taking a rather boring F35 SRPM and attempting to rebuild it in mock for  
F36.


Its stock configure script, that tries to test-compile conftest.c fails  
thusly:


gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches - 
pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,- 
D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack- 
protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1   - 
m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection - 
fcf-protection  -Wl,-z,relro -Wl,--as-needed  -Wl,-z,now - 
specs=/usr/lib/rpm/redhat/redhat-hardened-ld - 
specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -Wl,--build-id=sha1 -Wl,- 
dT,/builddir/build/BUILD/.package_note-courier- 
unicode-2.2.3.20220416-1.fc36.x86_64.ld conftest.c  >&5


/usr/bin/ld: cannot open linker script file 
/builddir/build/BUILD/.package_note-courier- 
unicode-2.2.3.20220416-1.fc36.x86_64.ld: No such file or directory


Looking at the output of rpm -q --showrc, this is apparently coming from a  
bunch of _package_note macros, including a -Wl,-dT flag that's referencing  
this .ld file that's nowhere to be found.


I can't immediately make heads or tails of these new macros, anyone know  
what this is all about, and what's missing from the spec file? Randomly, I  
added


%{_generate_package_note_file}

after %setup, in %prep, and that seem to get passed this error, is this  
really needed in every package that runs the linker?




pgpHeYI4KpJ9w.pgp
Description: PGP signature
___
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: No daemon-reload or restart with %systemd_postun_with_restart

[Sam Varshavchik]

Zbigniew Jędrzejewski-Szmek writes:


> > That the service is "oneshot" matters for the "restart" part. What
> > systemd actually does, is queue a "try-restart" job for the marked units.
> > Since this service is not running, that should become noop.
> > There seems to be a bug in the implementation though: try-restart always
> > restarts the unit → https://github.com/systemd/systemd/issues/22850.
>
> Are you saying that if it wasn't a oneshot service, it would get restarted?

No. I'm saying that oneshot services get restarted even if they shouldn't
due to a bug. So once you fix the path, I expect that you'll go from
no-restarts to sometimes-too-many-restarts ;)


Well, I got one restart in the bag, now. Whether I'll end up with too many  
restarts, that's something that only future will tell...


But this problem was very hard to see:

lrwxrwxrwx. 1 root root 7 Jul 21  2021 /lib → usr/lib

Having a package install its service file via /lib broke these triggers. And  
there was no outward sign that there was anything wrong. The service stops  
fine, and it starts just fine. Only a reload or a restart does not work and  
there's no blinking sign anywhere that tells you what's wrong, exactly.




pgpqg_Bahu1YY.pgp
Description: PGP signature
___
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: No daemon-reload or restart with %systemd_postun_with_restart

[Sam Varshavchik]

Zbigniew Jędrzejewski-Szmek writes:


There are two separate steps here: "daemon-reload" and "restart
testsystemd.service".  Systemd is complaining about "daemon-reload"
missing. It isn't internally cognizant of the fact that
testsystemd.service should be restarted, that is managed by the rpm
scriptlets and "needs-restart" markers. Internally, it just looks at
the file timestamps and knows that it has old config.
RemainAfterExit=true means that the service is pinned even though it
exited, so systemd remembers the old config of the service from before
the upgrade and hence the complaint. The warning goes away after
"daemon-reload".


The point is: WHY is there no daemon-reload?

The timestamps are going to get updated, as a result of theupgrade, whether  
the service is oneshot, or whatever. It doesn't matter.


This is the only thing that the systemd %postinst script inserts into the  
rpm:


if [ $1 -eq 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
   # Initial installation
   /usr/lib/systemd/systemd-update-helper install-system-units  
testsystemd.service || :

fi

And this is the postinstall script:

if [ $1 -ge 1 ] && [ -x "/usr/lib/systemd/systemd-update-helper" ]; then
   # Package upgrade, not uninstall
   /usr/lib/systemd/systemd-update-helper mark-restart-system-units  
testsystemd.service || :

fi

Looking at that, and at what's in /usr/lib/rpm/macros.d/macros.systemd, I  
see absolutely nothing that will execute a daemon-reload after an rpm update.


To me, it's seem rather obvious that an rpm update should trigger, in some  
form or fashion, a daemon reload. Either that, or systemctl should stop  
complaining about a daemon reload.


Note that this is separate from the fact that there's no restart, either.  
There are two issues here: no reload, and no restart.



That the service is "oneshot" matters for the "restart" part. What
systemd actually does, is queue a "try-restart" job for the marked units.
Since this service is not running, that should become noop.
There seems to be a bug in the implementation though: try-restart always
restarts the unit → https://github.com/systemd/systemd/issues/22850.


Are you saying that if it wasn't a oneshot service, it would get restarted?

That's weird. Because I have a Type=forking service right here that doesn't  
get restarted either.


My oneshot example was merely the most convenient reproducer that I could  
whip up on a moment's notice.


As far as I can tell, it doesn't matter what the service type is, forking or  
not, it does not get restarted. It merely gets marked, and I must manually  
run systemctl reload-or-restart --marked in order to actually restart it. I  
see nothing in the scriptlets that will do it for me.




pgpkZ7IKIHhJ0.pgp
Description: PGP signature
___
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: No daemon-reload or restart with %systemd_postun_with_restart

[Sam Varshavchik]

Ewoud Kohl van Wijngaarden writes:


On Mon, Mar 21, 2022 at 07:12:23PM -0400, Sam Varshavchik wrote:

Ewoud Kohl van Wijngaarden writes:


On Mon, Mar 21, 2022 at 08:27:35AM -0400, Sam Varshavchik wrote:

Ewoud Kohl van Wijngaarden writes:


On Fri, Mar 18, 2022 at 06:22:08PM -0400, Sam Varshavchik wrote:

The only thing that https://docs.fedoraproject.org/en-US/packaging-
guidelines/Scriptlets/ tells me to do is to put %systemd_postun_with_restart  
in my %post. However:


1) systemd complains that it wants a daemon-reload, in order to pick up an  
updated .service file


2) I still must manually run systemctl reload-or-restart --marked, in order  
to actually restart an updated service


It seems to be there's a missing step, in here. By comparison I prepared  
comparable .deb packages for Ubuntu, using dh_installsystemd in the install  
script. The end result:


A) The initial .deb install enabled and started the service.

B) Bumping the release, rebuilding, and installing the newer package results  
in an automatic daemon-reload and restart, restarting the service.


Overall .deb's systemd integration seems to go smoother (compared to the  
rest of the .deb packaging process) than rpm's.


Is there a specific reason why %systemd_postun_with_restart stops before  
finishing the job? Am I missing something that I can install, to have this  
happen auto-magically?


I think daemon-reload changed to file triggers in systemd 228:

https://github.com/systemd/systemd/commit/ 
873e413323dfff4023604849c70944674ae5cd29


However, the scriptlets documentation[1] states to use %systemd_post with  
%post and %systemd_postun_with_restart with %postun. %Perhaps that you're  
using %systemd_postun_with_restart in %post is the source of your problems?


No, my invocation is in %postun. Furthermore, it wouldn't matter, since at  
%post time the new package and the new service unit should already be  
installed and restartable.


And, as I wrote:

1) systemd complains that it wants a daemon-reload, in order to pick up an  
updated .service file


If ot was "changed to file triggers", well, it's not working since nothing  
is getting triggered. Furthermore, %systemd_postun_with_restart runs:


/usr/lib/systemd/systemd-update-helper mark-restart-system-units

which does:

systemctl set-property "$unit" Markers=+needs-restart &

That's all it does. Then, as I wrote:

2) I still must manually run systemctl reload-or-restart --marked, in order  
to actually restart an updated service


So, the shipped systemd scriptlets are still, very much, under an impression  
that explicit action needs to be taken to restart and/or reload  
updated .services. But, nothing gets reloaded. The .service files gets  
marked for a restart, but, from what I can tell, nothing ever gets restarted.


Do you happen to have the spec file and/or the RPMs? How can we replicate  
the findings?


Take the following spec file, below, and just feed it to rpmbuild -ba.

Then, rpm -ivh the binary rpm. Then:

systemctl enable testsystemd
systemctl start testsystemd
systemctl status testsystemd

You'll get something like this:

[mrsam@jack tmp]$ systemctl status testsystemd
● testsystemd.service - testsystemd
   Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; enabled;  
vend>

   Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 10s ago
  Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 88834 (code=exited, status=0/SUCCESS)
  CPU: 2ms

Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.

Up to now, everything looks good.

Now, take this spec file, bump the release, feed it to rpmbuild again.

According to my best understanding of systemd's published documentation:  
installing an updated package should automatically restart the active  
service, shouldn't it?


But after I fed the new version to rpm -UvhF, what I got was:

[mrsam@jack tmp]$ systemctl status testsystemd | cat
Warning: The unit file, source configuration file or drop-ins of  
testsystemd.service changed on disk. Run 'systemctl daemon-reload' to reload  
units.

● testsystemd.service - testsystemd
   Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; enabled;  
vendor preset: disabled)

   Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 4min 35s ago
  Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
 Main PID: 88834 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 76902)
   Memory: 0B
  CPU: 0
   CGroup: /system.slice/testsystemd.service

Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.

A loud complaint at the beginning that systemd wasn't reload. Same,  
unchanged, syslog timestamp from the initial start.


This is on up to date F35.

Then, at this point:

sudo systemctl daemon-reload
sudo systemctl reload-or-restart --marked

[mrsam@jack tmp]$ s

Re: No daemon-reload or restart with %systemd_postun_with_restart

[Sam Varshavchik]

Ewoud Kohl van Wijngaarden writes:


On Mon, Mar 21, 2022 at 08:27:35AM -0400, Sam Varshavchik wrote:

Ewoud Kohl van Wijngaarden writes:


On Fri, Mar 18, 2022 at 06:22:08PM -0400, Sam Varshavchik wrote:

The only thing that https://docs.fedoraproject.org/en-US/packaging-
guidelines/Scriptlets/ tells me to do is to put %systemd_postun_with_restart  
in my %post. However:


1) systemd complains that it wants a daemon-reload, in order to pick up an  
updated .service file


2) I still must manually run systemctl reload-or-restart --marked, in order  
to actually restart an updated service


It seems to be there's a missing step, in here. By comparison I prepared  
comparable .deb packages for Ubuntu, using dh_installsystemd in the install  
script. The end result:


A) The initial .deb install enabled and started the service.

B) Bumping the release, rebuilding, and installing the newer package results  
in an automatic daemon-reload and restart, restarting the service.


Overall .deb's systemd integration seems to go smoother (compared to the  
rest of the .deb packaging process) than rpm's.


Is there a specific reason why %systemd_postun_with_restart stops before  
finishing the job? Am I missing something that I can install, to have this  
happen auto-magically?


I think daemon-reload changed to file triggers in systemd 228:

https://github.com/systemd/systemd/commit/ 
873e413323dfff4023604849c70944674ae5cd29


However, the scriptlets documentation[1] states to use %systemd_post with  
%post and %systemd_postun_with_restart with %postun. %Perhaps that you're  
using %systemd_postun_with_restart in %post is the source of your problems?


No, my invocation is in %postun. Furthermore, it wouldn't matter, since at  
%post time the new package and the new service unit should already be  
installed and restartable.


And, as I wrote:

1) systemd complains that it wants a daemon-reload, in order to pick up an  
updated .service file


If ot was "changed to file triggers", well, it's not working since nothing  
is getting triggered. Furthermore, %systemd_postun_with_restart runs:


/usr/lib/systemd/systemd-update-helper mark-restart-system-units

which does:

systemctl set-property "$unit" Markers=+needs-restart &

That's all it does. Then, as I wrote:

2) I still must manually run systemctl reload-or-restart --marked, in order  
to actually restart an updated service


So, the shipped systemd scriptlets are still, very much, under an impression  
that explicit action needs to be taken to restart and/or reload  
updated .services. But, nothing gets reloaded. The .service files gets  
marked for a restart, but, from what I can tell, nothing ever gets restarted.


Do you happen to have the spec file and/or the RPMs? How can we replicate  
the findings?


Take the following spec file, below, and just feed it to rpmbuild -ba.

Then, rpm -ivh the binary rpm. Then:

systemctl enable testsystemd
systemctl start testsystemd
systemctl status testsystemd

You'll get something like this:

[mrsam@jack tmp]$ systemctl status testsystemd
● testsystemd.service - testsystemd
Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; enabled;  
vend>

Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 10s ago
   Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
  Main PID: 88834 (code=exited, status=0/SUCCESS)
   CPU: 2ms

Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.

Up to now, everything looks good.

Now, take this spec file, bump the release, feed it to rpmbuild again.

According to my best understanding of systemd's published documentation:  
installing an updated package should automatically restart the active  
service, shouldn't it?


But after I fed the new version to rpm -UvhF, what I got was:

[mrsam@jack tmp]$ systemctl status testsystemd | cat
Warning: The unit file, source configuration file or drop-ins of  
testsystemd.service changed on disk. Run 'systemctl daemon-reload' to reload  
units.

● testsystemd.service - testsystemd
Loaded: loaded (/usr/lib/systemd/system/testsystemd.service; enabled;  
vendor preset: disabled)

Active: active (exited) since Mon 2022-03-21 19:02:37 EDT; 4min 35s ago
   Process: 88834 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
  Main PID: 88834 (code=exited, status=0/SUCCESS)
 Tasks: 0 (limit: 76902)
Memory: 0B
   CPU: 0
CGroup: /system.slice/testsystemd.service

Mar 21 19:02:37 jack systemd[1]: Starting testsystemd…
Mar 21 19:02:37 jack systemd[1]: Finished testsystemd.

A loud complaint at the beginning that systemd wasn't reload. Same,  
unchanged, syslog timestamp from the initial start.


This is on up to date F35.

Then, at this point:

sudo systemctl daemon-reload
sudo systemctl reload-or-restart --marked

[mrsam@jack tmp]$ systemctl status testsystemd
● testsystemd.service - testsystemd
Loaded: load

Re: No daemon-reload or restart with %systemd_postun_with_restart

[Sam Varshavchik]

Ewoud Kohl van Wijngaarden writes:


On Fri, Mar 18, 2022 at 06:22:08PM -0400, Sam Varshavchik wrote:

The only thing that https://docs.fedoraproject.org/en-US/packaging-
guidelines/Scriptlets/ tells me to do is to put %systemd_postun_with_restart  
in my %post. However:


1) systemd complains that it wants a daemon-reload, in order to pick up an  
updated .service file


2) I still must manually run systemctl reload-or-restart --marked, in order  
to actually restart an updated service


It seems to be there's a missing step, in here. By comparison I prepared  
comparable .deb packages for Ubuntu, using dh_installsystemd in the install  
script. The end result:


A) The initial .deb install enabled and started the service.

B) Bumping the release, rebuilding, and installing the newer package results  
in an automatic daemon-reload and restart, restarting the service.


Overall .deb's systemd integration seems to go smoother (compared to the  
rest of the .deb packaging process) than rpm's.


Is there a specific reason why %systemd_postun_with_restart stops before  
finishing the job? Am I missing something that I can install, to have this  
happen auto-magically?


I think daemon-reload changed to file triggers in systemd 228:

https://github.com/systemd/systemd/commit/ 
873e413323dfff4023604849c70944674ae5cd29


However, the scriptlets documentation[1] states to use %systemd_post with  
%post and %systemd_postun_with_restart with %postun. %Perhaps that you're  
using %systemd_postun_with_restart in %post is the source of your problems?


No, my invocation is in %postun. Furthermore, it wouldn't matter, since at  
%post time the new package and the new service unit should already be  
installed and restartable.


And, as I wrote:

1) systemd complains that it wants a daemon-reload, in order to pick up an  
updated .service file


If ot was "changed to file triggers", well, it's not working since nothing  
is getting triggered. Furthermore, %systemd_postun_with_restart runs:


/usr/lib/systemd/systemd-update-helper mark-restart-system-units

which does:

systemctl set-property "$unit" Markers=+needs-restart &

That's all it does. Then, as I wrote:

2) I still must manually run systemctl reload-or-restart --marked, in order  
to actually restart an updated service


So, the shipped systemd scriptlets are still, very much, under an impression  
that explicit action needs to be taken to restart and/or reload  
updated .services. But, nothing gets reloaded. The .service files gets  
marked for a restart, but, from what I can tell, nothing ever gets restarted.





pgpGqMkF3Gjib.pgp
Description: PGP signature
___
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

No daemon-reload or restart with %systemd_postun_with_restart

[Sam Varshavchik]

The only thing that https://docs.fedoraproject.org/en-US/packaging- 
guidelines/Scriptlets/ tells me to do is to put %systemd_postun_with_restart  
in my %post. However:


1) systemd complains that it wants a daemon-reload, in order to pick up an  
updated .service file


2) I still must manually run systemctl reload-or-restart --marked, in order  
to actually restart an updated service


It seems to be there's a missing step, in here. By comparison I prepared  
comparable .deb packages for Ubuntu, using dh_installsystemd in the install  
script. The end result:


A) The initial .deb install enabled and started the service.

B) Bumping the release, rebuilding, and installing the newer package results  
in an automatic daemon-reload and restart, restarting the service.


Overall .deb's systemd integration seems to go smoother (compared to the  
rest of the .deb packaging process) than rpm's.


Is there a specific reason why %systemd_postun_with_restart stops before  
finishing the job? Am I missing something that I can install, to have this  
happen auto-magically?




pgpI2u0fmirqR.pgp
Description: PGP signature
___
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

11 minutes to update the breeze-icon-theme package

[Sam Varshavchik]

I noticed that dnf update stuck for a while in the "Cleanup" phase of the  
breeze-icon-theme package.


At the time this was taken: it spent 10 minutes with the CPU pegged at 100%,  
and it eventually finished at about the 11 and a half minute mark, and  
completed the rest of the update:


Tasks: 330 total,   2 running, 324 sleeping,   0 stopped,   4 zombie
%Cpu(s):  8.8 us,  3.6 sy,  0.0 ni, 87.4 id,  0.0 wa,  0.1 hi,  0.0 si,  0.0 st
MiB Mem :  16002.0 total,   4592.0 free,   1188.6 used,  10221.4 buff/cache
MiB Swap:   1024.0 total,966.4 free, 57.6 used.  14398.6 avail Mem

   PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND
185190 root  20   0  563752 217788  31884 R  98.7   1.3  10:40.80 dnf


strace was showing that this was reading and writing to  
/var/lib/rpm/rpmdb.sqlite-wal which, here, is about 240mb in size.  
/var/lib/rpm/rpmdb.sqlite was 256mb (there's a lot of junk on this box due  
to its history).


rpm --rebuilddb removed rpmdb.sqlite-wal, and shrunk rpmdb.qlite to 128mb.

The breeze-icon-theme package installs 17513 files. I guess I'll have to  
wait until this package gets another update and see if the issue is with rpm  
grinding down on such a large package, or sqlite dbs accumulating cruft over  
time.




pgpgEnh19eQHU.pgp
Description: PGP signature
___
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: CVE-2021-4034: why is pkexec still a thing?

[Sam Varshavchik]

Lennart Poettering writes:


On Di, 01.02.22 09:01, Sam Varshavchik (mr...@courier-mta.com) wrote:

> And an isolated process will be capable of rate-limiting itself in this
> situation any better than a sudo process, which could do the same kind of
> rate-limiting itself, exactly how?

"Rate-limiting"? Not sure what "rate-limiting" has to do with any of
this.


Rate limiting is a generic term. It doesn't only mean "how often  
something happens". Anyway:



If priv code runs with extremely low prio, and acquires a shared
resource, that other priv code might wait for that isn't low prio,
then you have a classic prio inversion issue. because the higher prio
code will be slowed down to the level of the low prio process, which
can be used to DoS things.


The relevant part would be "limiting". Something that repeatedly does what's  
described here could be described as a rate-limiting problem, but that's a  
minor issue. More importantly: it seems to me that an isolated daemon which  
acquires the same resource, on behalf of a low-priority, unprivileged  
process, will also end up block a higher-priority unprivileged process from  
getting that resource, in the same manner. Not sure how this would address  
priority inversion.


Perhaps one can say that an isolated process might factor this in, then  
juggle the competing resource requests based on the requesters' priorities.  
But that sounds like a lot of work for me, and more complicated work for a  
privileged process to do. More opportunities for bugs to happen. Bugs in  
privileged processes are bad.


But I want to closely focus on the exact "shared resource" part here, and  
examine the actual requirements. I really don't like discussing things in  
this kind of a general manner. Practical details matter to me. I would like  
to dig into the specific, actual instance here, on its own merits.


Is this shared resource really needed to be used in the manner that makes it  
possible for priority inversion to happen; or can it be used differently,  
somehow, in a way to avoids it. The questions to answer should be a little  
bit more sophisticated than "how to remove an setuid bit from a program,  
this'll fix all the problems".



prio inversion issues are well known and more or less just bugs. But
they become a security issue once unpriv code has control of the prios
of priv code and can bring the system to a standstill hence. Which is
the case here with sudo.

(i.e. the fact that sudo dosn't at least do a simple
setpriority(PRIO_PROCESS, 0, 0); is beyond me...)


Maybe it should, maybe this is a good idea. Maybe it makes sense for a shell  
with elevated privileges to start with a lowered priority by default, and  
root would be able to elevate its privileges if needed. I don't play root  
very often, I have no opinion, but this is an unrelated topic.


But if I was convinced that it was a good idea then this is what I would do  
already: contacting the sudo-stewards and submitting a patch. It's worth a  
shot, and that's what I would do, if it bugged me. A few years ago, because  
of a crazy reason, I thought that adding a few bits to libxcb would be a  
useful thing to do, and I did exactly that. And they agreed!  So, rather  
than wondering, why doesn't X do Y, how about: take the bull by the horns  
and see what happens?



Yeah, OpenSSH split up its stuff into multiple processes that talk to
each other via IPC and where privs are never acquired, but only
lost. it's the perfect example of how to actually do things well, and
*not* using setuid because it's a broken design.


I would agree: having openssh being a suid program is …not recommended.


Anyway, I understand your love suid and sudo.


I love suid and sudo no more, no less, and exactly the same as I love my  
screwdriver. I'm married to neither. Both are just tools. Both can be used,  
by people, correctly. Both can be used also, by people, incorrectly. But it  
makes no sense to use that as a reason for replacing screwdrivers with  
wrenches.



But please accept that
some people, me being one of them, think the concept is a very bad
idea. Some others have voiced their takes already on this mailing
list.


I never claimed that others are not allowed to have different opinions, or  
there's something wrong with them if they do. I have to admit that a long  
time ago I might've believed something like that. But I'm older now and I  
recognize that others will have different opinions. I'm not affiliated with  
sudo, in any way, and have no skin in the game. If they choose to update  
sudo to work in the described way, more power to them and we'll see how that  
works out. If Fedora decides to get sudo replaced by some alternative that  
works this way, we'll see how well that works out too, when it happens.




pgpsrbL1UNcIV.pgp
Description: PGP signature
___
devel mailing list -

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

[Sam Varshavchik]

Lennart Poettering writes:


On Di, 01.02.22 07:14, Sam Varshavchik (mr...@courier-mta.com) wrote:

> Lennart Poettering writes:
>
> > On Mo, 31.01.22 18:32, Sam Varshavchik (mr...@courier-mta.com) wrote:
> >
> > > Lennart Poettering writes:
> > >
> > > > See the discussion around seccomp and NNP. i.e. a new kernel facility
> > > > was added precisely to ensure that seccomp cannot be used to run code
> > > > that is intended to be run privileged – under security policies in
> > > > control by an unprivileged user. i.e. if you can take certain privs
> > > > away from code that expects to have them you might be able to trigger
> > > > vulnerable codepaths that the developer didn't expect you to be able
> > > > to trigger.
> > > >
> > > > But anyway, don't focus so much in cgroups here. There are plenty
> > > > other props these days that sudo doesn#t clean up. consider this for
> > >
> > > Ok, so where's the track record of potential security exploits, in  
similar
> > > kinds of tools, that: 1) leverage any of the resources that you  
mentioned,

> > > and 2) but were mitigated, and became ordinary bugs, thanks to the
> > > vulnerable code being an isolated daemon process, with a clean
> > > environment.
> >
> > I already described you a vulnerability. And the vulnerabilities in
>
> I must've missed those descriptions. Is there a reference somewhere that I
> can read, which describes them.

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B2ZCFBIM3AWBUFJKNHGZWPLZZDZPH43Y/

I explained a locking DoS there: run privileged code, but with
extremly restrictive resource scheduling settings, so that it will
acquire privileged resources such as locks (which it can, since it is
privileged) but is extremely slow to give up again since it runs
awfully slow, due to the extremely restrictive resource settings which
are under control of an unpriv caller.


And an isolated process will be capable of rate-limiting itself in this  
situation any better than a sudo process, which could do the same kind of  
rate-limiting itself, exactly how?


About the only thing that works to its advantage is that it'll be in a  
better position to employ rate limiting, by its virtue of being persistent.


But if this is a concern, there's a much better, hybrid approach. The user- 
initiated executable would be a setuid executable that connects to a  
filesystem socket, with the permissions adjusted so that only a privileged  
process can connect to it.


This mitigates resource attacks that establish connections to the persistent  
daemon, and just hold them open, without doing anything. Depending on the  
particulars the setuid executable could do its own sanity checks first,  
before establishing a connection to the persistent daemon, for the next step  
in the process.


The suid bit itself is not a problem. Much like everything else, it is a  
useful tool when used correctly. But just because it is used incorrectly,  
sometimes, doesn't make it bad. And I tend to avoid making an absolute one- 
size-fits-all, blanket assumption on the order of "X is bad". That's a bit  
simplistic, and too naive for my taste. I'd rather take a look at each  
individual situation, on its own merits, and figure out the best solution.


An excellent example would be what happened to OpenSSH. My understanding is  
that they shuffled off all authentication stuff into a separate daemon that  
runs with restricted privileges. This is not quite a good analogue for sudo,  
there is no setuid bit involved here. But this is the right approach:  
analyze the individual situation, and figure out the best solution. For  
OpenSSH it seems to be what they picked to do, which makes a lot of sense.



> > sudo from not cleaning up env vars are pretty well documented, too no?
> > And they are the same kind: not cleaned up context.
>
> A basic search finds the most recent sudo exploit was a heap based buffer
> overflow in sudo about a year ago. Something that can equally happen in an
> isolated process, too, if triggered the same way.

CVE-2014-9680, CVE-2014-0106, CVE-2010-3853, CVE-2010-1646,
CVE-2008-3825, CVE-2006-0151, CVE-2005-4158, CVE-2005-3629,
CVE-2005-2959, CVE-2004-1051, CVE-2002-0043, …

These are all env var cleanup issues in su/sudo context.


Picking a few of them, at random:

CVE-2006-0151: https://bugzilla.redhat.com/show_bug.cgi?id=139478

# Statement for NVD:
#
# If an administrator is concerned that users who have been granted sudo  
# privileges can alter the environment, the existing "env_reset" option should  
# be used which cleans the whole environment.


Mic drop.

CVE-2005-3629: this is initscripts, not sudo, the topic here.

CVE-2008-3

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

[Sam Varshavchik]

Lennart Poettering writes:


On Mo, 31.01.22 18:32, Sam Varshavchik (mr...@courier-mta.com) wrote:

> Lennart Poettering writes:
>
> > See the discussion around seccomp and NNP. i.e. a new kernel facility
> > was added precisely to ensure that seccomp cannot be used to run code
> > that is intended to be run privileged – under security policies in
> > control by an unprivileged user. i.e. if you can take certain privs
> > away from code that expects to have them you might be able to trigger
> > vulnerable codepaths that the developer didn't expect you to be able
> > to trigger.
> >
> > But anyway, don't focus so much in cgroups here. There are plenty
> > other props these days that sudo doesn#t clean up. consider this for
>
> Ok, so where's the track record of potential security exploits, in similar
> kinds of tools, that: 1) leverage any of the resources that you mentioned,
> and 2) but were mitigated, and became ordinary bugs, thanks to the
> vulnerable code being an isolated daemon process, with a clean
> environment.

I already described you a vulnerability. And the vulnerabilities in


I must've missed those descriptions. Is there a reference somewhere that I  
can read, which describes them.



sudo from not cleaning up env vars are pretty well documented, too no?
And they are the same kind: not cleaned up context.


A basic search finds the most recent sudo exploit was a heap based buffer  
overflow in sudo about a year ago. Something that can equally happen in an  
isolated process, too, if triggered the same way.


A more careful search located the sudo exploit you described, from 2014,  
CVE-2014-0106. I couldn't find anything similar in sudo's history, so this  
must be what you are referring to. Looks like it was in a non-default  
configuration, and after reading up the details of the exploit:


The only argument I see here, is that if the isolated process-based  
implementation of an sudo-alternative did not implement the non-env_reset  
option in the first place. If it did implement the non-env_reset related  
option, presumably there would've been some mechanism for the client to  
transmit its environment to the isolated process, for the benefit of the  
spawned subshell.


And it that turned out to be the case, the same exact bug would've happened.  
The process isolation would not've accomplished anything, here. The problem  
was not inherent with an suid-based approach. sudo had a broken  
implemenation of an optional configuration setting. If it was broken in the  
same way, in an isolated process, the lack of the setuid bit would not've  
made any material difference.




pgpZwrbUzSEPJ.pgp
Description: PGP signature
___
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: CVE-2021-4034: why is pkexec still a thing?

[Sam Varshavchik]

Lennart Poettering writes:


See the discussion around seccomp and NNP. i.e. a new kernel facility
was added precisely to ensure that seccomp cannot be used to run code
that is intended to be run privileged – under security policies in
control by an unprivileged user. i.e. if you can take certain privs
away from code that expects to have them you might be able to trigger
vulnerable codepaths that the developer didn't expect you to be able
to trigger.

But anyway, don't focus so much in cgroups here. There are plenty
other props these days that sudo doesn#t clean up. consider this for


Ok, so where's the track record of potential security exploits, in similar  
kinds of tools, that: 1) leverage any of the resources that you mentioned,  
and 2) but were mitigated, and became ordinary bugs, thanks to the  
vulnerable code being an isolated daemon process, with a clean environment.


In absence of an established track record that demonstrates this, in  
practice, this becomes just a theory. So, I'm not sure that it's clear to me  
-- is this getting argued based on an established track record, with some  
data to look at, the shows – based on some basic metrics – the benefits of  
rewriting suid programs in this manner; or is this just a theoretical  
argument.


Every additional line of code written to architect a privileged process, in  
this new manner, is a potential spot for a new bug to grow.


Rolling out a brand-spanking update, with a new architecture, new  
bootstrapping mechanism, and a new unprivileged process will become a  
Pyrrhic victory a year later, when it turns out that the privileged process  
trusted input from the unprivileged process, as an indirect result of new  
serialization/deserialization code that had to be written. That's where the  
bulk of the work was. And validating the deserialized data structure was  
accidentally overlooked.


Or the new serialization/deserialization code has its own buffer overflows.  
That would be code that didn't exist in the original, monolithic setuid  
executable.




pgp55rJYDskLq.pgp
Description: PGP signature
___
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: CVE-2021-4034: why is pkexec still a thing?

[Sam Varshavchik]

Demi Marie Obenour writes:


What would break if sudo was replaced by an IPC service that ran
sudo as if it was setuid root, without it actually being setuid root?
I imagine the hardest part would be TTY handling, as not being able
to Ctrl-C a command launched by sudo is a rather poor user experience.


File descriptors can be sent across filesystem sockets, this can be done.  
Once that's over the fence, perusing the relevant man pages suggests a  
combination of setpgid and tcsetpgrp should get the job done.


But, still: every additional line of code written to implement something is  
an additional line with a potential bug. In a security-sensitive context, it  
won't surprise me if trying to chase the separated server process unicorn  
ends up creating more bugs than a simple suid program ever had in its  
decades' of existence.




pgp4xGszFYaqp.pgp
Description: PGP signature
___
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: CVE-2021-4034: why is pkexec still a thing?

[Sam Varshavchik]

Lennart Poettering writes:


On Mo, 31.01.22 06:28, Sam Varshavchik (mr...@courier-mta.com) wrote:

> > I vehemently disagree. The thing with setuid/setgid is that the
> > invoked privileged process inherits a lot of implicit state and
> > context that people aren't really aware of or fully
> > understand. i.e. it's not just env vars and argv[], it's cgroup
> > memberships, audit fields, security contexts, open fds, child pids,
> > parent pids, cpu masks, IO/CPU scheduling priorities, various prctl()
> > settings, tty control, signal masks + handlers, … and so on.
>
> And none of that makes any difference, whatsoever, unless there's also an
> underlying logical bug in the code itself.

That's what you hope. But because there are *so* many properties of a
process these days, and it's not entirely obvious what gets inherited
and what not and what the effect of it is, that it's very hard to
clean it up, and I'd even claim impossible.


I would like to see some hard data here: how many exploits, historically,  
leveraged all those ancillary, inherited process metadata that would not've  
worked if the targeted process had this ideal environment.


An argument is being advanced that having an isolated process, with a clean  
environment, would be an effective mitigation strategy that prevents  
exploitable vulnerabilities.


This should be demonstrable with prior art. Of course, it's fair to include  
the other side of the coin: documentation of incidents where there was no  
exploit clearly because of the isolated process's environment blocking any  
exploitation of a bug. Both, I think would be fair to cite as a  
authoritative data.


So, where's the prior art?


> Stuff that's "added all the time" won't be used in existing code base, and
> will be immaterial. None of the stuff from semi-recent history (containers,
> CPU affinities, etc…) appears to have much effect on my existing setup.

suid processes didn't use to be a member of a cgroup. Now they
are. Security policy is tied to cgroups (i.e. see bpf cgroup stuff),
so suddenly bpf some stuff affects suid programs that they weren#t
affected by before.


And when the cgroups did not exist, when everyone lives in the same sandbox,  
something would stop the same, exact, exploitable program from exploiting  
whatever it coulf exploit as part of the cgroup, and with no other  
differences? Continuing with Star Trek quotes: as Mr. Spock would say "this  
is highly illogical".


It's difficult to talk in generalities but, presumably, prior to cgroups,  
the other actor that's involved in this theoretical exploit might've used  
some other access control mechanism, or authentication mechanism.


With the same exploitable program, it will either be able to leverage the  
other actor, before cgroups, with its alternative access control mechanism,  
or not. The prior security model was, presumably scrapped in favor of  
cgroups. That, as I understand, is the described scenario here.


So, the grand total that I see here: if the prior security model also didn't  
stop the same exploit being leveraged, then cgroups made no difference. If  
it did, switching to cgroups made it worse.


And in both cases, the issue is the nature of the actual bug in the  
exploitable program, and not anything else. Suid is just a scapegoat.




pgpV1sx3dVyIw.pgp
Description: PGP signature
___
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: CVE-2021-4034: why is pkexec still a thing?

[Sam Varshavchik]

Lennart Poettering writes:


On Fr, 28.01.22 18:16, Sam Varshavchik (mr...@courier-mta.com) wrote:

> Having said all of that: the suid bit itself is irrelevant. It is nothing
> more than a convenient scapegoat to blame other bugs on. The same bug  
that's
> exploitable in a suid binary will also be exploitable, exactly the same  
way,

> in its suid-less equivalent. If you have a buffer overrun in a suid binary
> as a result of carefully-crafted command-line parameters or environment,
> then if you replace the suid binary with an identical bug-for-bug
> implementation that uses a socket to carefully pass along the same
> environment or parameters to a native root binary, and the buffer overrun  
is

> the same, guess what: you still have the same exploit.

I vehemently disagree. The thing with setuid/setgid is that the
invoked privileged process inherits a lot of implicit state and
context that people aren't really aware of or fully
understand. i.e. it's not just env vars and argv[], it's cgroup
memberships, audit fields, security contexts, open fds, child pids,
parent pids, cpu masks, IO/CPU scheduling priorities, various prctl()
settings, tty control, signal masks + handlers, … and so on.


And none of that makes any difference, whatsoever, unless there's also an  
underlying logical bug in the code itself. And that's going to be the real  
problem. So then, question becomes, how many exploits leveraged any of these  
exotic resources, like cgroup members, tty control, and all of those other  
fringe attributes? I suppose there might've been a few, but I can't recall  
many. On the other hand, exploits that accomplish execve("/bin/bash") would  
work equally well, given the same underlying bug in the root daemon, that's  
triggerable via its front end, or in a suid program. A sanitized environment  
won't be much of a help.


Give me a suid program doing a fgets() with a wrong buffer size on a stack  
array. Then also give me a program that connects to a root daemon over a  
socket, then simply forwards all input to it, with the root daemon also  
doing the same exact buffer overrun. The exploit will be the same. The root  
daemon's pristine, pure as wind-driven snow, environment won't make any  
difference.


In fact, having extra moving pieces only breeds more opportunities for bugs.  
There are still too many simpletons who are going to conclude that the right  
way to go is by doing all edit checking in the wrapper, then passing  
validated data to the daemon who'll assume its validity.


"The more you overthink the plumbing, the easier it is to stop up the  
drain." – Scotty, Star Trek III.




> suid is not the problem. An execved program will inherit the environment,
> some open file descriptors, and maybe a few other things that a standalone
> daemon that accepted a socket connection does not have. But that's what  
most

> exploits leverage, so cleaning up the environment and open file descriptors
> would remedy that. It will take some effort to exploit whatever
> remains.

IRL you cannot clean up your execution context, because new stuff is
added all the time. And often enough it's not even clear whar reset it
to, e.g. cgroup stuff.


Stuff that's "added all the time" won't be used in existing code base, and  
will be immaterial. None of the stuff from semi-recent history (containers,  
CPU affinities, etc…) appears to have much effect on my existing setup.




pgpum4oRyqCIY.pgp
Description: PGP signature
___
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: CVE-2021-4034: why is pkexec still a thing?

[Sam Varshavchik]

Florian Weimer writes:


> Well, that's precisely the problem that PK was supposed to address,
> but then it descended down the JS rabbit hole...

Not sure if we are talking about the same thing.  I meant flooding the
local socket (or similar) with requests, not access control.


Create a filesystem socket. Set the socket's UID, GID, and chmod.  
Abracadabra: same initial access control as execve. I don't recall off the  
top of my head whether you need r, w, x, or some combination of these to be  
able to connect() to it, but whatever they are: set it. I also don't recall  
whether ACLs would also work, but at least without ACLs you get the same  
level of control as an executable binary.


Then, demand an SO_PASSCRED as the first order of business, on every new  
connection: now you have exactly the same information to work with as a SUID  
executable.


I can't think of any reason why su/sudo cannot be implemented this way.

Having said all of that: the suid bit itself is irrelevant. It is nothing  
more than a convenient scapegoat to blame other bugs on. The same bug that's  
exploitable in a suid binary will also be exploitable, exactly the same way,  
in its suid-less equivalent. If you have a buffer overrun in a suid binary  
as a result of carefully-crafted command-line parameters or environment,  
then if you replace the suid binary with an identical bug-for-bug  
implementation that uses a socket to carefully pass along the same  
environment or parameters to a native root binary, and the buffer overrun is  
the same, guess what: you still have the same exploit.


suid is not the problem. An execved program will inherit the environment,  
some open file descriptors, and maybe a few other things that a standalone  
daemon that accepted a socket connection does not have. But that's what most  
exploits leverage, so cleaning up the environment and open file descriptors  
would remedy that. It will take some effort to exploit whatever remains.


If you wrote a suid program, and did not wipe out your char **environ, or  
went through and closed any lingering file descriptors, your problem was not  
your suid bit, but something else.




pgpORP9dsoEYP.pgp
Description: PGP signature
___
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: During the first update after installation: Failed to connect to bus: Invalid argument

[Sam Varshavchik]

Peter Boy writes:


While updating right after installation of Fedora Server 35 today I get:

>   Running Scriptlet:  
tzdata-2021b-1.fc35.noarch 306/306

> Failed to connect to bus: Invalid argument
>
> Failed to connect to bus: Invalid argument
>
> Failed to connect to bus: Invalid argument
> Failed to connect to bus: Invalid argument
>
>   Verifying: clevis-pin- 




I didn’t found any issues yet.

Anyone else got these messages?


Yes. Multiple bugs were filed. They are being closed as dupes of 2020415.

The bug was opened for a different problem. Once it was fixed, this spam  
started showing up. This bug was reopened.


Who knows what spam will show up after this bug gets fixed…



pgps4XOm6wWKi.pgp
Description: PGP signature
___
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 3x slower boot than F34

[Sam Varshavchik]

Vitaly Zaitsev via devel writes:


On 05/09/2021 09:55, Philip Rhoades via devel wrote:
My response to situations in the past where resolving the SELinux issue was  
opaque (usually to do with MTAs if I recall correctly) . . was just to  
disable SELinux and move on . .


In over 10 years with Fedora, I've only had some SELinux problems. Fixed  
quickly after filling out RHBZ report.


I've had a few.

Bug 1913276 was opened past January for a very obscure package named  
"NetworkManager". I guess few people use it, so it does not seem to be a  
priority.


Bug 1859974 was opened a year ago for the same obscure package, which blocks  
it from configuring certain run of the mill VPN configurations. It was not  
actioned, and EOLed. I guess this will remain broken. Who needs VPN  
connections, anyway?


Bug 1909522, same time frame. This package doesn't ship with Fedora, but  
selinux-policy-targeted provides a policy for it, and this is just one of  
the problems that I documented.


The background here is that Fedora, overall, would be quite useless if you  
can only run stuff on it that came in the distribution. So, obviously, it  
should be possible to build and install common software packages that just  
happens to be not in the distribution.


Now combine this with the fact that SELinux has to be enabled by default,  
and you wind up with the situation of SELInux maintainers having to write  
SELinux policies for stuff that's not even in the distribution, and that  
they don't fully understand (this is not a criticism, just a statement of  
fact).


I recall a few others, that I could probably dig up. Does this make sense to  
anyone?


I'm not complaining about this bug here, or the bugs that I cited. The  
problem is not the bugs, it's why these bugs keep happening in the first  
place.




pgpLRWr3k5Zih.pgp
Description: PGP signature
___
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 3x slower boot than F34

[Sam Varshavchik]

Vitaly Zaitsev via devel writes:


On 05/09/2021 14:52, Sam Varshavchik wrote:
if only a great, overwhelming majority of Fedora package maintainers were  
able to write policies for their own packages and maintain it themselves  
because SELinux documentation was ample and easy to fllow


https://pagure.io/packaging-committee/issue/726
https://fedoraproject.org/wiki/SELinux_Policy_Modules_Packaging_Draft


Which parts of the above describe, and explain, how to write the SELinux  
policy itself? Once it's written that's a great piece of documentation to  
follow, to explain how to package this policy. But this is putting the cart  
before the horse. The package maintainers have to actually understand how to  
write SELinux policies, first.


The problem isn't the technical details of how to package an SELinux policy  
with the packge.


The problem is the domain knowledge needed to write that SELinux policy in  
the first place. It's siloed mostly in the selinux package itself. I assert  
that the documentation above is not going to be useful to 95% of the package  
maintainers. A few of them will know how to write a policy, and then follow  
the above wiki. The rest will not. Prove me wrong.


I posted this link before:

https://raw.githubusercontent.com/svarshavchik/libcxx/master/packaging/fedora/libcxx.te

Where is the documentation that explains /all/ of the above, and what it  
means? I wrote that policy, of course, but even now, just a short time  
later, I can't for the life of me tell you where all that documentation is.  
Because there isn't, I had to figure out based on scraps of other selinux  
policies that I looked at, and based on my experience with other stuff that  
did NOT involve SELinux.


You will not find any documentation that explains /all/ of that on  
https://selinuxproject.org


And at most 5% of the above is explained in

https://selinuxproject.org/page/RefpolicyWriteModule

And until the state of the world is such that SELinux is not a siloed  
domain, that it's amply documented, and package maintainers have  
documentation that they can use to write their own policy, for the package  
that they fully understand and support, SELinux will continue to break  
random stuff, over and over again.




pgp0igdvnSnmA.pgp
Description: PGP signature
___
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 3x slower boot than F34

[Sam Varshavchik]

Vitaly Zaitsev via devel writes:


On 05/09/2021 09:19, Peter Boy wrote:
Much to my chagrin, you describe the biggest problem in Fedora for years and  
the one why Fedora is falling further and further behind among  
distributions. The problem overshadows all that many positive features that  
otherwise distinguish Fedora.


SELinux has saved Fedora users from many critical vulnerabilities (eg.  
telnetd RCE CVE last year). This is a last line of defense.


Great. If only SELinux wasn't such a siloed domain; if only a great,  
overwhelming majority of Fedora package maintainers were able to write  
policies for their own packages and maintain it themselves because SELinux  
documentation was ample and easy to fllow; then these constant AVC failures  
would likely be a thing of the past.




pgpQOiEKzxs4J.pgp
Description: PGP signature
___
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 3x slower boot than F34

[Sam Varshavchik]

Miroslav Suchý writes:


Dne 04. 09. 21 v 17:28 Sam Varshavchik napsal(a):
Are you a package maintainer? Ok: please write an selinux policy for your  
package. Let me know when that's done.


https://pagure.io/copr/copr/blob/main/f/selinux

You are welcome.


You did that 7 years ago, according to change history.

Today, I count >50k packages in Fedora. I'm going to wild guess that the  
number that install their own policy files is probably under a hundred.  
Based on nothing more than my gut feeling. Everything else falls under the  
shoulders of the global selinux-policy-targeted package to support.


Let's suppose that you are a maintainer of some software package that builds  
and installs on Fedora, but fails to run with multiple AVC. You have a  
general awareness of selinux and what's it's all about. You even understand,  
more or less, what security contexts are, and what "ls -Z" tells you.


So, you want to provide a policy files? How long will it take you to figure  
out how to do that? As I mentioned in my case it was a week, calendar time;  
and may be about 8 hours of total brainpower expended. In the grand scheme  
of things this may not be too bad, but I do have a problem with how I ended  
up finally writing that thing, and I didn't really walk away with it feeling  
that I actually learned anything.


I didn't find a lot of useful reference material. Nothing like the web  
version of "Maximum RPM", which I used to learn how to package stuff using  
rpm. I was hoping for something similar for SELinux, but I came away  
disappointed.


There are no manual pages or documentation to be found, in either  
selinux-policy-targeted or selinux-policy devel. The biggest collection of  
information I could find was one single page:  
https://selinuxproject.org/page/RefpolicyWriteModule – that's pretty much  
all that I had to work with, together with other scraps and tidbits from  
whatever I could find in Google, most of which was outdated. Also by looking  
at random files in the selinux packages. Even though I wound up with  
something that made those AVCs go away, I don't have a lot of confidence  
that the policy is as stringent as it should be.


And now looking back at my policy file, and comparing it with that wiki  
page, I see that:


1) Somehow I had to learn about the "require" directive, and which  
requirements I need to pull into my policy file.


2) Somehow I had to figure out what domain_auto_trans(), type_transition()  
did, to make my package work. I wrote this policy file two years ago. I no  
longer remember what they actually do. A Google search for  
"domain_auto_trans site:selinuxproject.org" finds a wiki page where it's  
mentioned in a cryptic comment, and that's pretty much it. A search for  
"type_transition" gets an actual wiki page, but I just read it and it's all  
a foreign language to me now.


3) I also see that my cobbled policy has a "fs_associate_tmpfs" and  
"kernel_dgram_send", and a metric ton of others that have no hits at all, in  
what I understand to be is the reference SELinux site. They must be macros  
defined in Fedora's selinux policy file. I did a global Google search. The  
only hits I found were on http://oss.tresys.com/, which, I suppose, is  
progress.


Here's what I wrote, back in the stone ages:

https://raw.githubusercontent.com/svarshavchik/libcxx/master/packaging/fedora/libcxx.te

This is what I ended up doing, to make my AVCed go away. Someone can tell me  
whether this looks right, or is a horrible, horrible mess.


A. It's a horrible mess. Sorry, but that's what the best I could do using  
publicly available information. I don't think I'm dumber than the next guy,  
but I'm open to be proven wrong. Until that time, this must mean that  
someone who's unfamiliar with SELinux will end up making a horrible mess,  
for the crime of attempting to make their software work on Fedora.


B. This looks right. How many people can raise their hand and say that,  
today, they understand what every part of this does (I'm keeping my hand  
down). And would you say that it's reasonable to expect anyone who wants to  
develop on Fedora, and make their non-trivial software package work on  
Fedora, with SELinux, to figure out how to write this goo?


I can see why there constant problems with SELinux issues in Fedora. Few  
understand it, outside of those who work on the core selinux package itself.  
SELinux has been around for a long time, and I would expect that these  
things to have been ironed out by now. The fact that it's not indicates a  
conceptual problem somewhere.


Does this really scale? Does it make sense for Fedora to continue to grow,  
but the task of carrying selinux in working order, for the /entire/  
distribution falling on the same set of shoulders, on one package? I would  
argue that it makes much more sense for packages to install their own policy

Re: F35 3x slower boot than F34

[Sam Varshavchik]

Stephen Gallagher writes:


So it appears to be an SELinux issue. I suspect but cannot prove that
it's related to a number of AVCs related to DBUS that I see in
selinux-troubleshooter.


I've watched SELinux come into existence, and its evolution over the years.

It's clear to me that SELinux, let's say diplomatically, hasn't lived up to  
its expectations. The expectations in questions would be: it has an  
established mindshare; and software package maintainers can easily write,  
have clear documentation to follow, and ship selinux policies for their  
packages.


Has this been happening? Of course not. Can anyone ever see this happening?  
Nope.


Instead what we have now is siloed selinux package maintainance, with the  
selinux package responsible for constantly revising and updating a  
SYSTEMWIDE security policy, covering ALL packages in the distribution, in  
addition to popular software packages that are often installed, but not a  
part of the core distribution.


Does this state of affair seem logical to anyone?

SELinux maintainers can't be expected to be familiar what each and every  
package does, and constantly stay up to date with any updates in this area.


This situation will never improve. Stuff will continue to break, with  
selinux. It will have to be constantly fixed. Hopefully. If it can be fixed  
in the first place.


A more sensible approach would be for individual package developers and  
maintainers install their package's selinux policy together with the  
package, and maintain it. That makes too much sense, doesn't it?


But it will never happen. Maybe my Google skills are rusty. Maybe my brain  
has atrophied. But I don't see, speaking very generally, how can anyone can  
avoid pouring a massive amount of time into figuring out how to write an  
SELinux policy for a package whose inner workings they can understand.


SELinux's policy file syntax is unlike any other syntax of any other  
configuration system I know off. I searched, but could not find any tutorial  
or any sort of a guide to writing SELinux policies, or explain what /any/ of  
the cryptic statements in the existing selinux policy files do.


Are you a package maintainer? Ok: please write an selinux policy for your  
package. Let me know when that's done.


If one wants to learn how to write an rpm spec file, one can actually find  
useful documentation, even entire books on it. Although some of the info  
there is somewhat outdated, it's more than enough to get started, and learn  
enough to be able to figure out the missing pieces.


Can someone post a link to the SELinux equivalent to the "Maximum RPM" book?

Nobody was surprised more than me when I was able to cobble together an  
selinux policy file from scratch that allowed me to install and run my  
library, with a network server daemon. But it took over a week. It should've  
taken five minutes. That's what it actually took to physically type it. But  
it took over a week of frantic digging all over every corner of the  
intertubes, and countless cycles of "enable enforcing, wait until something  
breaks, look at the AVC message, grep the existing policy files for  
something that seems to define the capabilities that are missing, add them  
the policy file, recompile and reinstall it. This is not a practical way of  
implementing an SELinux policy.


Only Fedora, IIRC, has selinux enabled by default. None of the other  
distributions have it turned on out of the box. Maybe someday SELinux has  
ample documentation, and is easy to configure and set up, for a given  
package, by the package's maintainers with just a minimal learning effort.  
Maybe someday there will no longer be a need to have a dedicated team of  
gurus who are the only ones that really know how it work, in order to  
support it. Until such day arrives Fedora will continue to be dragged down,  
and hobbled by having to have SELinux enabled by default.





pgpfhiIzO3NoC.pgp
Description: PGP signature
___
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 regression: nouveau crashes on kernel 5.12

[Sam Varshavchik]

Tim Jackson writes:

I'm unfortunately no expert in this area, but as far as I can tell,  
certain(?) chipsets using the nouveau driver fail to resume from suspend on  
all 5.12 kernels, which leaves the system in an apparently unrecoverable  
state requiring a hard reboot. The same hardware configuration has worked  
perfectly for me for several years through a number of Fedora releases.


Suspend on my laptop with nouveau hasn't worked in at least ten years (ever  
since I had it), much longer before kernel 5.12.


Interestingly enough, on this laptop and laptop alone I'm offered a "Hybrid  
Sleep" alternative which works fairly reliably. It does, occasionally, fail  
to wake up, getting stuck in a weird "try to wake up, go back to sleep"  
infinite loop that only a hard power reset can cure. But it hasn't done that  
in a long while, maybe someone found this bug and fixed it. Keeping my  
fingers crossed.




pgp1xmt2KqcAn.pgp
Description: PGP signature
___
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: The future of legacy BIOS support in Fedora.

[Sam Varshavchik]

Marius Schwarz writes:


Am 30.06.20 um 15:34 schrieb Jóhann B. Guðmundsson:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it  
beg the question if now would not be the time to stop supporting booting in  
legacy bios mode and move to uefi only supported boot which has been  
available on any common intel based x86 platform since atleast 2005.


Now in 2017 Intel's technical marketing engineer Brian Richardson revealed  
in a presentation that the company will require UEFI Class 3 and above as in  
it would remove legacy BIOS support from its client and datacenter platforms  
by 2020 and one might expect AMD to follow Intel in this regard.


This will fail i.e. on M$ Surface Pro * systems.

Also, a lot of laptops are installed in Legacy Mode, as setting them up in  
EFI was impossible.


I have two servers that predate 2005. They've been running Fedora just fine  
since then, with no problems whatsoever. Back then, server-level hardware  
was built to last. I know that at least one of them does not support EFI.


It a shame if Fedora were to abandon its long-time users. This proposal was  
already brough up earlier this year and was described as a non-starter back  
then. I haven't paid attention and I hope this is still a non-starter;  
otherwise, as I said, it will be a shame.




pgpYYqMjShRjV.pgp
Description: PGP signature
___
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: Remove old GPG keys?

[Sam Varshavchik]

Miroslav Suchý writes:


Dne 03. 05. 21 v 17:06 Sam Varshavchik napsal(a):


Yeah, so:

1) Someone has to remember to do this as part of every release

2) This doesn't do anything about add-on repositories' keys

3) I had pgp keys going all the way to F19, etc…

My approach is slightly awkward


*nod* would you mind add clean-rpm-gpg-pubkey to Fedora? Then I can simply  
call it.


It's been a long, long time since I packaged something. Life happens, etc…  
We'll see, can't make any promises…




pgp0CuKvhQlxa.pgp
Description: PGP signature
___
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: Remove old GPG keys?

[Sam Varshavchik]

Miroslav Suchý writes:


Dne 03. 05. 21 v 0:18 Sam Varshavchik napsal(a):
Yes, I'm replying to this old thread. See it in the list archives. And,  
since then, doesn't look much has changed. Old pgp keys are still gathering  
dust, in everyone's rpm databases.


I had nothing else to do this lazy Sunday afternoon, so I finally decided to  
do something about it. This cleaned up over 40 old PGP keys from one of my  
laptop:


https://github.com/svarshavchik/clean-rpm-gpg-pubkey


You inspired me to do:

https://github.com/xsuchy/fedora-upgrade/commit/ 
138fa54b62c633c6435a86eaf53b0ed44ae48fe5


Although I chosen to remove only enumerated keys.


Yeah, so:

1) Someone has to remember to do this as part of every release

2) This doesn't do anything about add-on repositories' keys

3) I had pgp keys going all the way to F19, etc…

My approach is slightly awkward -- having to manually parse the conf files  
and perform release and arch substitution. But it has the advantage of  
pretty much figuring everything out. It also did me a favor and found some  
old conf files on one of my servers, that ages ago I used – my dim  
recollection – to do an upgrade from a throwaway local repo, and so the  
repo conf referenced keys that did not exist. It was nice to clean that up.




pgpfVzGVJABVD.pgp
Description: PGP signature
___
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: Remove old GPG keys?

[Sam Varshavchik]

> I just stumbled upon
>   https://unix.stackexchange.com/questions/400634/does-anyone-bother-to-rem...
> with the nice link to:
>   https://blog.laimbock.com/2014/05/02/how-to-remove-an-imported-gpg-key-fr...
> And I wonder: is it a good idea to keep old gpg keys in RPM db? Or should we 
> automate the
> removal of old keys?

Yes, I'm replying to this old thread. See it in the list archives. And, since 
then, doesn't look much has changed. Old pgp keys are still gathering dust, in 
everyone's rpm databases.

I had nothing else to do this lazy Sunday afternoon, so I finally decided to do 
something about it. This cleaned up over 40 old PGP keys from one of my laptop:

https://github.com/svarshavchik/clean-rpm-gpg-pubkey
___
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: Don't update to the latest f33!

[Sam Varshavchik]

Steve Dickson writes:




On 2/15/21 6:19 PM, Sam Varshavchik wrote:
> Steve Dickson writes:
>
>> Hello,
>>
>> I just updated to latest Fedora 33 and
>> I no longer have any DNS name solution.
>> The network is up... but...
>>
>> $ ping www.yahoo.com
>> ping: www.yahoo.com: Name or service not known
>>
>> I changed nothing!
>>
>> How would be the bet way to debug this???
>
> Inspect what it's your /etc/resolv.conf, confirm that your name server is  
127.0.0.10, or something this bizarre.

I guess it is bizarre...
# See man:systemd-resolved.service(8) for details about the supported modes  
of

# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad

>
> Now look in /run/NetworkManager/no-stub-resolv.conf to see what your real  
DNS server is. Let's assume that you see it's 8.8.8.8, but you should be  
able to recognize your usual DNS server in there.

# cat /run/NetworkManager/no-stub-resolv.conf
cat: /run/NetworkManager/no-stub-resolv.conf: No such file or directory

Who is suppose to create that? It is on /run so it be created on every  
reboot...


NetworkManager. Maybe you have /run/NetworkManager/resolv.conf, I have both  
of them. I'm too lazy to look up what's the difference.


> Now, perform a test lookup using the dig command, directly, to your real  
DNS server.

>
> dig @8.8.8.8 www.yahoo.com
I can't do this because bind-utils was not install and I can not install it
because DNS is broken..


"host" has an optional second parameter, the DNS server's IP address.




pgp42E_pY3uee.pgp
Description: PGP signature
___
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: Don't update to the latest f33!

[Sam Varshavchik]

Steve Dickson writes:


Hello,

I just updated to latest Fedora 33 and
I no longer have any DNS name solution.
The network is up... but...

$ ping www.yahoo.com
ping: www.yahoo.com: Name or service not known

I changed nothing!

How would be the bet way to debug this???


Inspect what it's your /etc/resolv.conf, confirm that your name server is  
127.0.0.10, or something this bizarre.


Now look in /run/NetworkManager/no-stub-resolv.conf to see what your real  
DNS server is. Let's assume that you see it's 8.8.8.8, but you should be  
able to recognize your usual DNS server in there.


Now, perform a test lookup using the dig command, directly, to your real DNS  
server.


dig @8.8.8.8 www.yahoo.com

Make sure you use the IP address you got from no-stub-resolv.conf

Assuming that this lookup succeeds, proceed as follows:

systemctl stop systemd-resolved
systemctl disable systemd-resolved
rm -f /etc/resolv.conf
ln -s ../run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf

Verify that your DNS service is now working, then announce that you joined  
the systemd fan club, and ask for your membership information.





pgpWzRAprEgzl.pgp
Description: PGP signature
___
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: dropping php-imap (was Re: Orphaned packages looking for new maintainers)

[Sam Varshavchik]

Joe Orton writes:


On Mon, Feb 08, 2021 at 06:43:29PM +, Gwyn Ciesla via devel wrote:
> Can uw-imap be replaced with something else, or should someone pick it up?

There has not been an upstream release since 2007 - the maintainer Mark
Crispin sadly died in 2012, and nobody else has formed an upstream
around it.


It's my recollection that Mark Crispin was let go at the University of  
Washington some years prior to that (I distinctly recall a message to  
comp.mail.imap noting that), and uw-imap's ownership and maintenance was  
picked up by whoever remained over there.




pgpFniz2qjwdI.pgp
Description: PGP signature
___
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: COMMERCIAL - Bosch - Architect

[Sam Varshavchik]

George Bastin writes:


Sorry Marius, it is not a violation of any law.


Right. By the way, banning everyone from an organization from using a  
mailing list: that's not a violation of any law, either. It would also not  
be a violation of any law to notify administrators of other mailing lists  
what a certain organization tends to use mailing lists for. This will also  
be perfectly legal.


You address is on a public mailing list, which anyone in the world can  
contact.


A "public mailing list" is not a synonym for being open to "anyone in the  
world can" to send any message, on any topic, to the mailing list. I'm  
wondering what you would think about me sending a picture of my cute kitty- 
cat to this mailing list. Would that be appropriate? How come? After all,  
this is a public mailing list, and that's the only justification you offered  
for your action, quote: this is a "public mailing list". There were no  
further constraints. So, if this is good enough for your email, it should be  
good enough for my email too, with a picture of my kitty-cat.





pgpZDZKu0LSqH.pgp
Description: PGP signature
___
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: DNF/RPM Copy on Write enablement for all variants (System-Wide Change)

[Sam Varshavchik]

Neal Gompa writes:

On Mon, Dec 21, 2020 at 1:14 PM Marius Schwarz   
wrote:

>
> If something really needs to change, it is the 50+ MB repo database that
> gets downloaded. It takes ages on slow connections to download
> and than you want to increase the size of the rpms too.. Doesn't sound
> like a good idea.
>

You should be getting delta fetching of repository metadata with
zchunk metadata, which we've had enabled since Fedora 30:
https://fedoraproject.org/wiki/Changes/Zchunk_Metadata

Is this not working for you or something?


Well, I don't know what's working for me, or not working for me. All I know  
is that:


1) I'm rsyncing the updates repo to my LAN, and other machines in my lan  
have the default updates repo disablde and a replacement repo pointing at my  
local copy.


2) Even on the LAN, an update downloads something from the local repo,  
giving me a zippy progress indication of the download. After the download it  
sits for a noticeable amount of time before it decides exactly what it's  
going to update and then gives me the list. This is especially noticable for  
a Fedora VM guest that I'm running in a VM that's emulating an aarch64  
platform. In the emulated aarch64 VM downloading of RPMs goes a bit slow,  
but the subsequent pause after download is quite noticable.


Except for rsyncing a mirror of the updates repo locally and then pointing  
everyone to my local mirror, I am not doing any other customization and  
that's the behavior I've seen.


Having said all that, I don't find the update process to be that much of a  
pain point right now, and in any dire need of improvement. It works. It is  
fairly reliable. A bit slow, but who cares. The important thing is that  
except for a burst of segfaults downloading rpms earlier this year (haven't  
had any in a while) it's been rock stable and hiccups are very, very rare. I  
don't exactly see what's the big value-added from the described feature  
enhancement, I'd only want to make sure it's just as stable.




pgpZBUJUKA6HS.pgp
Description: PGP signature
___
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: gpg-agents all over the place

[Sam Varshavchik]

Roberto Ragusa writes:


On 12/16/20 2:55 AM, Kevin Kofler via devel wrote:


Believe it or not, GNU/Linux is no longer a text-only operating system, nor
are window managers just a container for terminal emulators. :-)


But that is different than saying the GNU/Linux has become a no-text  
operating system.Version 2 of gpg is impossible to use in scripts.


Oh, look, someone else is using scripted build tools that use gpg. Nice to  
meet you.




pgp3f2OhEUyKU.pgp
Description: PGP signature
___
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: gpg-agents all over the place

[Sam Varshavchik]

Kevin Kofler via devel writes:


Sam Varshavchik wrote:
> But, for some reason that I do not understand, the existing terminal
> interface always gets broken.

Well, how prompts in terminal emulator sessions in the GUI should work is a
design decision. Some people (like you, apparently) expect them to behave
the terminal way (so the isatty check is the right one for them), whereas
others expect them to behave the GUI way (so the code checks whether a GUI
agent is running, and only falls back to a TTY prompt if there is none in
scope – not sure whether GPG gets this right, but most agent interfaces are
implemented like that).


If, and if, it actually behaved this way, and actually worked as advertised,  
I would not object to entering my password into a popup dialog.


But it never worked this way. Perhaps because the terminal session is an ssh  
session from another host. Now, you aren't going to start an agent on the  
host I'm ssh-ing from (and who's to say that the origin host even has an X  
session, it does in my case but that's not guaranteed either), even with X  
forwarding. X forwarding can't do that. And starting an agent on the  
headless server I've ssh-ed into is not going to accomplish anything.


And just to make sure that things haven't changed since the last time I  
wrestled with this: they haven't. I moved gpg-agent.conf out of the way,  
made sure that no stray gpg-agent processes are anyway. End result:


mrsam@jack ~]$ gpg --sign z
[one minute delay]
gpg: signing failed: Timeout
gpg: signing failed: Timeout

Found a gpg-agent process running at this point. What it was doing, for a  
minute or so, who knows. Maybe it's trying to pop up a dialog on the  
headless server I've ssh-ed into, instead of actually looking at DISPLAY  
that tunnels X over the ssh connection.


Even if I unset DISPLAY before running "gpg --sign z", it still hangs for  
about a minute, before deciding that whatever it's doing doesn't work and  
then runs pinentry-curses to prompt for the password. It does so rather  
rudely, taking over the entire terminal, but at least it gets restored  
afterwards.


I haven't looked at the code, so I have no idea if it's technically  
impossible, for some reason, to simply check DISPLAY, and if unset fallback  
to pinentry-curses immediately, instead of standing around and looking at  
each other. That's the very first though that occured to me, when this whole  
thing broke: should just do that.


But, anyway, before all this jazz with gpg-agent things just …worked. I ran  
gpg, it prompted for the password, I typed it in, and it was a done deal.  
Sadly for things to remain simple and work by default is out of fashion now.  
It's quite acceptable now for things suddenly break one fine day, until I  
waste away the whole day plumbing the depth of Google to find out I have to  
drop an explicit


pinentry-program /usr/bin/pinentry-curses

into ~/.gnupg/gpg-agent.conf in order for thing to continue limping along,  
as they did before.




pgpvSj5Rfmhq2.pgp
Description: PGP signature
___
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: gpg-agents all over the place

[Sam Varshavchik]

Kevin Kofler via devel writes:


Sam Varshavchik wrote:
> I miss the days when gpg needed a passphrase it simply prompted a message
> on standard output, turned off tty echo, and just read the password that I
> typed in.
>
> But that was too simple, primitive, and bulletproof. I guess that things
> can't be as simple any more, and the forward march of progress is
> unstoppable.

That approach simply does not work for GUI applications.


Sure. But it seems that more often that not making things work for GUI  
applications must mean that plain text interface ends up being broken.


   if (isatty(2))
   {
/* Existing code, that prompts for a password or reads it from stdin */
   }
   else
   {
/* The GUI equivalent */
   }


Now, your terminal interface continues to work as before, and you can  
provide a GUI interface too.


But, for some reason that I do not understand, the existing terminal  
interface always gets broken.




pgpZndKZe7ZHK.pgp
Description: PGP signature
___
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: gpg-agents all over the place

[Sam Varshavchik]

Marius Schwarz writes:


Hi,

I sorry to tell you, that gpg-agents are inflating on numbers in Fedora  
systems:


I miss the days when gpg needed a passphrase it simply prompted a message on  
standard output, turned off tty echo, and just read the password that I  
typed in.


But that was too simple, primitive, and bulletproof. I guess that things  
can't be as simple any more, and the forward march of progress is  
unstoppable.


The most simple interface I could get working these days is the curses  
pinentry. And that was no easy task to set up. I had to do some serious  
googling around, and sifting through the manual pages, to come up with the  
right set of spells and magic woids and phrases (I'm channeling Bugs Bunny)  
to make it happen.


it would be more effective, if you give any programm who needs it, the  
password directly, instead of having useless processes laying around ;)


Nah. That's too simple of a solution.


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


Any changes will likely need to originate upstream; I'll be surprised if  
there'll be any Fedora-originated development on this topic.


Systemd opens gpg-agents even for mailserver daemons, which do not need nor  
know how to use them.


Oh, sure. I had a nagging feeling something was missing, here. systemd,  
that's it.


No idea what caused this invasion lately, but bugreports about it, get  
ignored.


The drive to fix this needs to come upstream. But nobody pays attention any  
more to the simpletons like us, who like to work in a terminal or, heavens  
forbid, an ssh connection. Or (and I know how this can be shocking to hear)  
run build scripts. Everyone expects to have pretty windows, menu, dialogs,  
and animated gophers to join them on their quest to use gpg. Hence, the  
agent.



Could someone please take a look and fix it, if it's bug.


I would be very happy if someday I can simply run gpg(2) and have it simply  
prompt me for my password, by default, without me having to fiddle anything,  
not gpg-agent.conf, not anything else. Alas, I've resigned to those simpler  
days being just a fond memory.




pgpendVy3XHgz.pgp
Description: PGP signature
___
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: Serial Console with Fedora 33

[Sam Varshavchik]

Steve Dickson writes:


Hello,

How does one set up a serial console with F33?

In the past I would edit kernelopts with grub2-editenv
and set "console=tty0 console=ttyS0,115200n8".

As well as set the following in /etc/grub2.conf
terminal_output console
#set timeout=5
serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1
terminal_input serial
terminal_output serial

But in Fedora 33 there is no kernelopts in the grub2 env,
so does one create a serial console in f33?


There could be several places where your kernel boot options are stored. The  
safest way to avoid creating a brick is to use grubby. Its command line  
options are a bit of a bear to decipher, but it's a pretty safe way to go.




pgpD_LEl4eRu4.pgp
Description: PGP signature
___
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.

[Sam Varshavchik]

Arnoldas Skinderis writes:



I'am also have Thikpads and MSI running BIOS and some of those machines   
still are the beast in some terms. Dropping BIOS would pretty much force me  
to use something else.

I don't want to lose Fedora.


Ditto. My Thinkpad W520 is the best damn Fedora laptop. Ever. I have two  
newer laptops, they run Fedora just fine, but the legendary Thinkpad  
keyboard is generations ahead of the crappy chiclets on the other one.


Laughably easy to maintain. In the ten or so years I had it, I only had to  
replace that keyboard once, that's it. Oh, and put a new touchpad sticker,  
to replace the worn-out membrane cover.


This beast, as long as it can still run Fedora, will likely outlive me, and  
I'll have to will it to someone…




pgpXQY6J1Akw_.pgp
Description: PGP signature
___
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

Including local repos in a mock build

[Sam Varshavchik]

Is there a better way to include local repos in mock builds than doing  
something like this in my /etc/mock/default.cfg:


include('fedora-32-x86_64.cfg')

config_opts['dnf.conf'] = config_opts['dnf.conf'] + """

[my]
name=My repository
baseurl=http://jack/repos/$releasever/$basearch
enabled=1
gpgcheck=0
metadata_expire=60

"""


I might be misremembering something, but I'm pretty sure that at some point  
in the past mock would read /etc/yum/repos.d, and grab stuff from my local  
repos without doing anything like that.




pgpINhtBkRQAI.pgp
Description: PGP signature
___
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.

[Sam Varshavchik]

Solomon Peachy writes:


Even putting that aside, for the past several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.


That's only because it's Microsoft.

I have ten year old hardware that runs just fine, and boots Fedora just  
fine. It's built like a tank, it's just as zippy as the day it was new, and  
this old Thinkpad will probably outlive me.


It will be a sad day when I can continue to order minor replacement parts  
off Amazon, to replace the few worn out ones, but I can't install Fedora on  
it.




pgpESjd6k6Vfl.pgp
Description: PGP signature
___
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 Jam switch to GNOME

[Sam Varshavchik]

er...@ericheickmeyer.com writes:


Anyhow, I'd love to see a discussion about this as well as any guidance
toward making this change. I know there would have to be a new
kickstart along with Koji pointing toward said kickstart. I could make
the kickstart, but I think I'd need Koji to look for it.


Have you considered XFCE? For me, XFCE is a breath of fresh air. It's a  
traditional desktop environment, that always feels like a comfortable, well  
worn pair of shoes.


And to your comment about attitudes, I can only say that I had one  
opportunity to report a bug, it was received well and addressed.




pgpaYaBDQ4PJ_.pgp
Description: PGP signature
___
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 CPU extensions can we assume are available by arch?

[Sam Varshavchik]

Richard Shaw writes:

I'm having trouble determining what the base CPU targets for Fedora can  
accommodate.



For example, ss it safe to assume AVX2 on x86_64? 


Nope.

Linux thinkpad 5.5.16-200.fc31.x86_64 #1 SMP Wed Apr 8 16:43:33 UTC 2020  
x86_64 x86_64 x86_64 GNU/Linux

[
/proc/cpuinfo:

flags   : ... avx ... 

Last year a proposal was floated to require avx2 for Fedora 3-something. It  
didn't go well.




pgptHZAbRBITt.pgp
Description: PGP signature
___
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: gpg check failure installing from rawhide

[Sam Varshavchik]

Kevin Fenzi writes:


On Sat, Mar 07, 2020 at 09:47:03AM -0500, Sam Varshavchik wrote:
> Trying to follow the direction for a bug report against kernel, and install
> the latest kernel from rawhide.
>
> The Bugzilla template says:
>
> 5. Does this problem occur with the latest Rawhide kernel? To install the
>   Rawhide kernel, run “sudo dnf install fedora-repos-rawhide“ followed by
>   “sudo dnf update --enablerepo=rawhide kernel“:
>
> On F31, right now, 'dnf update --enablerepo=rawhide kernel' wants to  
install

> 5.6.0-0.rc4.git0.1.fc33, which fails the gpg check:
>
> Public key for kernel-core-5.6.0-0.rc4.git0.1.fc33.x86_64.rpm is not
> installed. Failing package is: kernel-core-5.6.0-0.rc4.git0.1.fc33.x86_64
> GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31- 
x86_64

>
> So, something, somewhere, needs to be fixed, either the Bugzilla template,
> or something related to signing.

Hum, yeah, thats a though one.

I guess the better command might be:

sudo dnf update --releasever 33 --enablerepo rawhide kernel

but of course there's no way to know '33' is right there unless you
know. This could be made better moving forward when we land the
'rawhide' is called 'rawhide' and not the number change.


That attempt still doesn't quite work:

Warning:  
/var/cache/dnf/rawhide-2d95c80a1fa0a67d/packages/kernel-5.6.0-0.rc5.git0.1.fc33.x86_64.rpm:  
Header V3 RSA/SHA256 Signature, key ID 9570ff31: NOKEY
Fedora - Rawhide - Developmental packages for t 0.0  B/s |   0  B  
00:00
Curl error (37): Couldn't read a file:// file for file:///etc/pki/rpm- 
gpg/RPM-GPG-KEY-fedora-33-x86_64 [Couldn't open file /etc/pki/rpm-gpg/RPM- 
GPG-KEY-fedora-33-x86_64]
The downloaded packages were saved in cache until the next successful  
transaction.


After doing a whatprovides on that, ended up install fedora-gpg-keys-33 with  
nogpgcheck. That allowed the rawhide kernel package to be installed.


Of course, installing fedora-gpg-keys-33 conveniently uninstalled fedora-gpg- 
keys-31. Can't win 'em all.

___
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

gpg check failure installing from rawhide

[Sam Varshavchik]

Trying to follow the direction for a bug report against kernel, and install  
the latest kernel from rawhide.


The Bugzilla template says:

5. Does this problem occur with the latest Rawhide kernel? To install the
  Rawhide kernel, run “sudo dnf install fedora-repos-rawhide“ followed by
  “sudo dnf update --enablerepo=rawhide kernel“:

On F31, right now, 'dnf update --enablerepo=rawhide kernel' wants to install  
5.6.0-0.rc4.git0.1.fc33, which fails the gpg check:


Public key for kernel-core-5.6.0-0.rc4.git0.1.fc33.x86_64.rpm is not  
installed. Failing package is: kernel-core-5.6.0-0.rc4.git0.1.fc33.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31- 
x86_64


So, something, somewhere, needs to be fixed, either the Bugzilla template,  
or something related to signing.




pgpY9zzIiGkep.pgp
Description: PGP signature
___
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: g++ 10: static declared in extern "C" inline function

[Sam Varshavchik]

Iñaki Ucar writes:


On Sun, 9 Feb 2020 at 14:20, Sam Varshavchik  wrote:
>
> Iñaki Ucar writes:
>
> > Thoughts?
> >
> > [1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c
>
> I managed to find the part of the C++ standard that specified the semantics
> of extern "C" linkage, it is [dcl.link]. The term used is "language  
linkage".

>
> There is no such thing as an inline function in C. That code compiles C++
> code with C language linkage.
>
> Reading the C++ standard,, all that the standard seems to specify is
> language linkage of declarations. Quoting:
>
> # Every implementation shall provide for linkage to functions written in  
the C

> # programming language, "C", and linkage to C ++ functions, "C++".
> #
> # [ Example:
> # complex sqrt(complex);
> #  // C++ linkage by default
> # extern "C" {
> # double sqrt(double);
> #  // C linkage
> # }
> # — end example ]
>
> The standard does not seem to specify the definitions of functions inside
> a language linkage specification. Either that is unspecified and therefore
> is a compiler extension; or it is clear that the only thing that belongs
> inside extern "C" is C code, and there's no such thing as inline functions
> in C, so declaring C++ code with C linkage would also be considered a
> compiler extension.
>
> This code compiles in gcc 9, but not in gcc 10. That's life, for compiler
> extensions.

So, summing up, nothing wrong with that code according to the
standard. Therefore, since this is a regression that breaks previous
behaviour, I'd say this is a bug in gcc, right?


No, exactly the opposite. As I wrote:


> Reading the C++ standard,, all that the standard seems to specify is
> language linkage of declarations.


The code that fails to compile is not a declaration. It defines an inline  
C++ function. I find nothing in C++ standard that specifies function  
definitions inside linkage specifications.


This is a declaration:

void foo();

This is a definition:

void bar()
{
}




pgpmQbf8EyTMR.pgp
Description: PGP signature
___
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: g++ 10: static declared in extern "C" inline function

[Sam Varshavchik]

Iñaki Ucar writes:


Thoughts?

[1] https://gist.github.com/kevinushey/cfa848be2d39ddd110f893d9b6c5ac9c


I managed to find the part of the C++ standard that specified the semantics  
of extern "C" linkage, it is [dcl.link]. The term used is "language linkage".


There is no such thing as an inline function in C. That code compiles C++  
code with C language linkage.


Reading the C++ standard,, all that the standard seems to specify is  
language linkage of declarations. Quoting:


# Every implementation shall provide for linkage to functions written in the C
# programming language, "C", and linkage to C ++ functions, "C++".
#
# [ Example:
# complex sqrt(complex);
#  // C++ linkage by default
# extern "C" {
# double sqrt(double);
#  // C linkage
# }
# — end example ]

The standard does not seem to specify the definitions of functions inside  
a language linkage specification. Either that is unspecified and therefore  
is a compiler extension; or it is clear that the only thing that belongs  
inside extern "C" is C code, and there's no such thing as inline functions  
in C, so declaring C++ code with C linkage would also be considered a  
compiler extension.


This code compiles in gcc 9, but not in gcc 10. That's life, for compiler  
extensions.




pgpzys8IBYkpI.pgp
Description: PGP signature
___
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 50+ RPM Subpackages too extreme?

[Sam Varshavchik]

Chris writes:


Hi guys,


I just wanted to poll you for some advice.  My notification tool I maintain  
supports more than 50+ services now, but the only package isolation I do


You should really count the number of texlive subpackages…




pgpeYylRqybGZ.pgp
Description: PGP signature
___
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: Encrypted DNS in Fedora

[Sam Varshavchik]

Florian Weimer writes:


* Michael Cronenworth:

> On 11/4/19 2:17 PM, Florian Weimer wrote:
>> We are not going to implement this directly in glibc.  You should talk
>> to a stub resolver on 127.0.0.1 instead.  We do not want to link a
>> cryptographic library into every process that queries an Internet host
>> name.  That also applies to DNSSEC.
>
> The transition to DoT/DoH makes the resolv.conf file obsolete. Any
> discussion on removing it entirely? Default to looking at a local
> resolver.

This is the default today.  The issue is that the defaults for the DNS
search path and some other options are wrong, and we will need a
transition to correct that.  Then we can probably remove the file,
unless something else is stored there.


Where would the dhcp-supplied DNS resolver, and DNS search path, go?

Ubuntu's default configuration appears to set up a stub resolver on  
localhost and dnsmasq. Made it somewhat difficult to do any kind of  
diagnostics, sine the real DNS server IP address seems to get stored  
entirely within dnsmasq, and not visible anywhere.


I like plain text files, in well-defined locations. Makes things much easier  
to troubleshoot.




pgpaH1FVGXQko.pgp
Description: PGP signature
___
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: No longer supporting mailing lists:

[Sam Varshavchik]

Markus Larsson writes:


« HTML content follows »


On 26 August 2019 12:56:42 CEST, "Gerald B. Cox"  wrote:

What issues are you referring to? I don't believe it is reasonable to
believe everything would work exactly the same with Discourse - but
close enough should be sufficient. There are also myriad advantages to
Discourse.


Are these advantages actually documented somewhere?
This move to discourse issue seems to pop up ever so often.
People always claim that there are a tonne of advantages but there rarely are  
any mention of actual advantages.


I have all my mail sitting right here. I am subscribed to a bunch of mailing  
list. They all end up in my mailbox, which makes it convenient for me,  
whenever I get around to it, to go through my mailing lists, and catch up on  
the latest goings on, here and there.


The mail is sorted the way I want to, organized in my folders according to  
my preferences.


There's only one place I need to go to catch up on all discussions, both on  
this list, and others.


To read all my mailing lists, I do exactly the same thing: open each folder,  
in turn, quickly browse through the subjects, read what I can find  
interesting, delete the rest, then move on to the next mailing. Quick.  
Convennient.


If I were to keep track of all the different web sites, and have to keep  
track of all the bookmarks somewhere, and learn how to use all the different  
web software out there, it would take me five to ten times as long to do the  
same thing. I'll probably spend more time browsing through each day's  
activity (assuming that each web discussion forum even offers the laughably  
simple feature of showing me only new messages that I haven't seen before)  
waiting for each page to load, then actually reading it.


I wouldn't even bother.

I'll just stick to mailing lists.

If this one goes away, that's very unfortunate. But I'll still have plenty  
of other mailing lists, to pass away the time with.




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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Sam Varshavchik]

Tom Hughes writes:


On 06/08/2019 09:37, Miroslav Lichvar wrote:


Ok, but does that mean the program has to abort? Could gcc do anything
dangerous here? If we were actually trying to catch undefined behavior
(e.g. with -fsanitize=undefined), I suspect Fedora wouldn't even boot
without a crash.


Well of course the program doesn't have to abort - we have chosen to
compile in a mode where it does.

We do that because by default this is invoking the nasal daemons clause
and the compiler is allowed to do absolutely anything it feels like.


Earlier in the thread I posted some conflicting references from the  
standard, related to the additional requirements of contiguous containers,  
and the specification of the "*" operator, that leaves some room open for  
interpretation, here.


If you go by the formal specification of container and iterator  
requirements, this is undefined behavior. But std::vector is also specified  
as having "additional" requirements of a "contiguous container", whose  
semantics are specified in terms of std::addressof behavior, and that rabbit  
hole goes in a slightly different direction.





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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Sam Varshavchik]

Georg Sauthoff writes:


> I ended up tweaking my code to avoid the assertions, rather than disabling
> them. For this particular situation, my original change was to try
>
> std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});
>
> But that still tripped the assertion when the foo vector was empty, so I  
had

> wrap this inside an if().

But why don't you use the idiomatic

copy(foo.begin(), foo.end(), back_inserter(bar));

?

No need to wrap it into an extra if statement.


I'm well aware of the alternatives. That's not the point.

The point is that there's nothing wrong with this specific form of existing  
code that now throws exceptions when the hardened build gets turned on.  
There is no buffer overruns, and nothing to exploit.


IIRC, the hardened build did find one real bug in the upstream package that  
was the original subject matter here, but all of the rest were these kinds  
of false positives. Now you have a situation when the existing code is known  
to be working, but needs changing in order to use a hardened build. There's  
some level of risk of regression in any change, and that gets weighed  
against the benefits of having a hardened build.


The above was just a basic example of this. It is not true that exceptions  
from hardened code are always evidence of potentially exploitable problem.  
Sometimes/most of the time, but sometimes they are false positives.





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

Re: How do I remove GLIBCXX_ASSERTIONS?

[Sam Varshavchik]

Andrew Lutomirski writes:


On a cursory search of the standard, I couldn't find where it says
what operator* on this type of iterator does at all, let alone whether
it's valid for one-past-the-end iterators, but I'm pretty sure that
your code is, indeed, wrong.


This finally piqued my curiosity enough to take some time to look into this.  
That expression applied the "*" operator to a random access iterator. So,  
going down the path:


# [random.access.iterators]
#
# A class or pointer type X satisfies the requirements of a random access 
# iterator if, in addition to satisfying the requirements for bidirectional 
# iterators, ...


In a similar fashion, a bidirectional iterator delegates some requirements  
to a forward iterator.


The forward iterator delegates some of its requirements to an input iterator.

At the end of the road, in [input.iterators]:

#  *a  reference,   convertible to T Requires: a is dereferenceable.

Then, finally, in [iterator.requirements.general]:

# Values of an iterator i for which the expression *i is defined are called 
# dereferenceable.


This reads to me like a definition that circularly defines itself. 
[input.iterators] says "*a requires that a is dereferencable". And  
[iterator.requirements.general] says that something is dereferencable if "*"  
for it is defined. That certainly clears that up…


Full disclosure: it's true that the next sentence is:

# The library never assumes that past-the-end values are dereferenceable.

But this only states that the library assumes that, it doesn't  
authoritatively state that.


But going back to the previous point, if we also want to see what going down  
"*i refers the unary * operator" route, as a means of avoiding the self- 
definition, we see that:


# [expr.unary.op]
#
# The unary * operator performs indirection: … the result is an lvalue

Nothing here requires the pointer to be valid, just that "*" gives you an  
lvaule. Nothing more, nothing else. That's it. Whether the pointer is valid,  
this gets punted only when the lvalue-to-rvalue conversion take place:


# [conv.lval]
#
# ... if the object to which the glvalue refers contains an invalid pointer
# value the behavior is implementation-defined.

But if you immediately apply the & operator, this conversion never takes  
place.


The C standard is even more explicit, and even blesses this  
construct, verbatim:


# The unary & operator yields the address of its operand.
# [ … ]
#
# if the operand is the result of a [] operator, neither the & operator  
# nor the unary * that is implied by the [] is evaluated and the result is as  
# if the & operator were removed and the [] operator were changed to a +  
# operator


I could not find some similar verbiage in the C++ standard, but based on all  
of the above I have to conclude that this is …too late today, and I should  
really get some sleep…


But not after rereading the specification for a vector itself, where I found  
something I glossed over the first time:


# [vector]
#
# A vector satisfies all of the requirements of a container and … of a 
# contiguous container.


The reference from "contiguous container" goes to:

# [container.requirements.general]
#
# A contiguous container is a container that supports random access iterators
# and whose member types iterator and const_iterator are contiguous iterators.

The reference from "contiguous iterators" goes to:

# [iterator.requirements.general]
#
# Iterators that further satisfy the requirement that, for integral values
# n and dereferenceable iterator values a and (a + n), *(a + n) is
# equivalent to *(addressof(*a) + n), are called contiguous iterators.

There might be more to the "contiguous" semantics that reflects on whether  
or not "[foo.size()]" is defined behavior, or not, but here  
addressof(*a) already puts us squarely in pointer equivalence territory, and  
seems to again go into the unary "*" operator direction here, despite the  
conflicting wording.


…now it's definitely too late in the day.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: How do I remove GLIBCXX_ASSERTIONS?

[Sam Varshavchik]

Tom Hughes writes:


But I think upstream is giving very bad advice...

That define does not "add extra crashes" in the way that they
seem to think - well I mean it does literally but those crashes
are reports of program errors on their part.

Specifically in this case they appear to be accessing a
std::vector at an index beyond the end, so they are accessing
memory that may not be allocated at all, and if it is does
not belong to the vector in question. So the program is quite
likely to crash there one day anyway, the extra assertion just
makes sure it always does.


I believe that the following construct trips this assertion:

# std::vector foo;
#
# std::vector bar;
#
# // Populate foo with something.
#
# std::copy([0], [foo.size()], std::back_insert_iterator{bar});

There's nothing wrong with this. There is no out of bounds access. I do not  
believe that this is undefined behavior. The defined semantics of  
std::vector, and its operator[], are well defined here.


I ran into these new assertions with my own code as well, after updating to  
F28 (where they were enabled by default the first time, IIRC, not sure why  
this shows up only now, for that package).


I ended up tweaking my code to avoid the assertions, rather than disabling  
them. For this particular situation, my original change was to try


std::copy([0], [0]+foo.size(), std::back_insert_iterator{bar});

But that still tripped the assertion when the foo vector was empty, so I had  
wrap this inside an if().


This was a somewhat silly excersize. But, I do agree that these assertions  
are better to have, than have not.




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

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

[Sam Varshavchik]

A brief survey of my hardware and less than half of it supports avx2.

I can't find a single enthusiastic endorsement for this proposal in this  
thread, so far; but if this proposal ends up being adopted, I hope that this  
gets announced well in advance, including a big fat banner on  
https://www.fedoraproject.org, to give everyone in the community plenty of  
time to make their own arrangements, in liue of that decision.




pgpQjHTQWEMrE.pgp
Description: PGP signature
___
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: Reporting is disabled because the generated backtrace has low informational value

[Sam Varshavchik]

Chris Murphy writes:


Please try to install debuginfo manually using the command:
"debuginfo-install flatpak-1.4.1-1.fc30" and try again.


That's your key piece of info. You're missing the debuginfo package, without  
it the backtrace has no info.


With a native, directly-installed RPM, the debug repo gets automatically  
enabled, and the debuginfo packages gets automatically fetched and  
installed. I guess with flatpacks, this is not automatic. Don't know much  
about flatpaks, but this is what you need to figure out how to make it  
happen.




pgpuCdmyAMWqj.pgp
Description: PGP signature
___
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

Bad locale environment in mock install

[Sam Varshavchik]

For some reason, a "mock install" ends up running %post scripts with  
LC_ALL=en_US.UTF8, for which I need glibc-all-langpacks.


This does not happen with a manual install from a mock shell.

The tiny spec file below reproduces the problem.

If I use "mock -n install" (I have a few other things in the chroot that I  
need), the log file shows that the locale is en_US.UTF8.


If I run a mock shell, and manully "rpm -i" inside the shell, the locale is  
the expected C.UTF-8


Anyone knows why I'm getting a bad locale, with mock install?

===

Summary: Locale in mock
Name: mocklocale
Version: 1
Release: 1
License: 1
Group: System Environment/Base

%description
test
%prep

%build

%install
rm -rf $RPM_BUILD_ROOT
mkdir -p $RPM_BUILD_ROOT

%clean
rm -rf $RPM_BUILD_ROOT


%files
%defattr(-,root,root,-)

%post
locale >/var/tmp/locale.log

%changelog
* Mon May  6 2019 Sam Varshavchik  -
- Initial build.



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

Re: Upgrade to F30 gone wrong

[Sam Varshavchik]

Chris Murphy writes:


In that case I expect that the rescue kernel+initramfs feature first
appeared in dracut in Fedora 19, so that's the first time it would
have noticed the pair are missing, and it would have created them at
that time. But that's just a guess.


This seems to be it. Two of my older BIOS systems, one still on F29, and one  
that's now on F30, both have a rescue image referencing Fedora 19 (the  
upgraded one referenced the rescue image in grub.cfg.rpmsave, pretty sure it  
still appears in the grub menu at boot time).




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

Re: Upgrade to F30 gone wrong

[Sam Varshavchik]

Chris Murphy writes:


If you see the rescue kernel+initramfs menu entry though, you do not
have the bug under discussion, and you don't need to run
'grub2-install' - your GRUB is by definition functioning fine if you
see this menu entry.


I just inventoried my bricks. One, which has not been updated to F30 yet,  
features this in its default.cfg:


menuentry 'Fedora 19 Rescue 929d17a456bf4083a935b6209da2ef46  
(3.9.8-300.fc19.x86_64)' --class fedora --class gnu-linux --class gnu -- 
class os $menuentry_id_option 'gnulinux-simple-6a70e79b-78da-487a-acfe- 
dfba88996747' {


So, it's a rescue from Fedora 19, which, from what I understand, is covered  
by the bug.


I have executed grub2-install manually on this machine, though, but I  
wouldn't expect it to figure out which release originally installed this  
kernel. And this machine was initially installed much, much earlier.





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

Re: Upgrade to F30 gone wrong

[Sam Varshavchik]

Steve Grubb writes:


Rescue mode? I couldn't find it. All references I could find to a rescue mode
date back to 2013 or later. I would have liked a rescue mode because makes it
easy to just chroot into your actual system from the livecd. Seems like we've
lost something nice if its really been dropped.


Somewhere around that era, installing Fedora added a grub menu entry for  
"Rescue" mode. I don't remember exactly what it was supposed to rescue, and  
how.


It's been sitting in the grub menu ever since.

I have a /boot/vmlinuz-0-rescue-f0fe67c2a80d43d2947358968ab5277e with a 2013  
timestamp. No idea which kernel it is. It appears to be immune to  
installonly_limit.



I wound up solving the problem by using the workstation livecd, mounting the
/boot partition, and issuing the grub2-install command. This worked, but the


https://fedoraproject.org/wiki/Common_F30_bugs#GRUB_boot_menu_is_not_populated_after_an_upgrade
offers a more simple bandaid.

Checking a "Common Fxx bugs" page before every upgrade has been a well- 
established ritual for quite some time.



I am thinking that something could have been put into dnf system-upgrade
where it could have warned about the problem or did a workaround. Actually,
this could still be put into system-upgrade because not everyone switches
first week or two because they are waiting to see what problems people hit
before doing it themselves.


That's what I suggested yesterday.



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

Re: Upgrade to F30 gone wrong

[Sam Varshavchik]

Chris Murphy writes:


This bug itself was expected to be an edge case, that not many users
would be affected, in that not many would have a stale Fedora 20 or
older bootloader. Surely 'grub2-install' would have been manually run,
or the user has done a recent clean install since Fedora 20, right?!


One of my bricks that will soon get Fedora 30 was originally installed with  
Fedora Core 4.


Obviously a minority; but you'll be surprised to learn how many systems  
there are which have been running Fedora for a very long time. Fedora 20 is  
what, about five years old? There are many, many systems which are at least  
five years old. People don't really swap hardware every 2-3 years, any more.




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

Re: Upgrade to F30 gone wrong

[Sam Varshavchik]

Chris Murphy writes:


Actually, that's a problem too. The stale bootloader problem goes back
to an era where it was possible to install the bootloader into the
first sector of the boot partition, and in those cases, /dev/sda1 is
actually valid. And again, no practical way to discover this
automatically in advance.


It would be useful to have dnf system-upgrade emit a "say, you may need to  
X first" message, before initiating a reboot, with an opportunity to bail  
out. Just like the existing message that tells you to update the current  
system first, before initiating an upgrade.


And, making this more generic, each new Fedora release could have a brief  
upgrade message tucked away in it, somewhere, that dnf system-upgrade could  
grab and show up front.




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

Re: IBM buying RedHat

[Sam Varshavchik]

Chris Murphy writes:


The reported deal is $34 billion, and Red Hat's closing market cap on
Friday was ~$20 billion, that's a big price premium. I'm not a lawyer
let alone a securities lawyer, but my guess is if Red Hat management
had refused the deal, I think they'd face shareholder lawsuits.


Yeah. I bought a little bit of RHAT when they went public. This is going to  
be a nice little return on my investment. Not a fortune, by any means, but  
certainly a nice little bonus. That's pretty much the only good thing I can  
think of, right now.





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

Re: hibernation — does it work for you?

[Sam Varshavchik]

Zbigniew Jędrzejewski-Szmek writes:


If you perform hibernation (systemctl hibernate, or the equivalent
through the GUI), does _your_ system suspend and resume correctly?

Note: I'm not talking about the user-space configuration issues
(resume= not set on the kernel command line, no swap, swap encrypted
with temporary keys, whatever), but only about any potential kernel
driver issues.


Well, I don't know if this a kernel or a userspace space issue, but neither  
hibernation nor suspension ever worked reliably on my Thinkpad W520. Every  
time  I tried to enable suspension it works maybe once or twice, but then  
eventually the laptop fails to come out of suspended state no matter what,  
so I end up power-cycling it, then turning off suspension in power  
management, and only have it turn the display off.


Hibernation never worked, to my recollection. Just tried to hibernate this  
laptop. The display flickered a few times, the laptop's speaker made a few  
reassuring beeps, then the whole thing turned itself off. The next boot was  
a normal boot. Normal grub menu, normal boot. No evidence of anything being  
hibernated. Probably a userspace issue, but I have no idea where to look.





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

Re: F29 Self Contained Change: Deprecate YUM 3

[Sam Varshavchik]

Jan Kurik writes:


= Proposed Self Contained Change: Deprecate YUM 3 =
https://fedoraproject.org/wiki/Changes/Deprecate_YUM_3


Owner(s):
  * Daniel Mach 


Remove yum (v3) and all related packages from Fedora.


== Detailed description ==
Remove packages from the distribution:
* createrepo


We should have createrepo_c install a symlink, and have an "Obsoletes:  
createrepo" so that this gets taken care of by a normal upgrade.




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

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

[Sam Varshavchik]

Hans de Goede writes:


For F29 the plan is to just hide it (unless a previous boot failed)


What is the exact criteria for "previous boot failed", I'm wondering. Even  
if you reach as far as the GDM screen it's still possible that something is  
so horked up to the point that you can't log in, and you can't shut down  
nicely.


I would also suggest that the criteria must include "something was not  
unmounted cleanly, so if we proceed we will be doing a fsck".


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

Re: F29 System Wide Change: Hide the grub menu

[Sam Varshavchik]

Jan Kurik writes:


= Proposed System Wide Change: Hide the grub menu =
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu


Owner(s):
  * Hans de Goede 


On systems with only a single OS installed, the grub menu does not
offer any useful functionality, so we should hide it by default.


Ummm, yes it does. It lets you boot into single user mode, or select the  
previous kernel to boot. That might be a critical function, in an emergency.


Here's a radical idea: just prompt this as an installation option.



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

Re: script to run after hotspot authentication?

[Sam Varshavchik]

Paul Wouters writes:



Hi,

Is there a way to run a custom command after hotspot authentication?

Fedora has/had some ways of detecting portals. dnssec-trigger,
NetworkManager and Gnome3. I think the current method is supposed
to be based on the latter. So I guess the problem that is used is
/usr/libexec/gnome-shell-portal-helper

Does that signal anything back to NM? It seems the helper itself has
no "post" commands it can run.

Specifially, I'm trying to solve the problem of IPsec MOBIKE support.
When we receive a notification of the new IP address via netlink, the
network isn't working yet and our mobike address update request using
this new IP address dies in the portal filter. The user authenticats
and the captive portal disables the filter, but we no longer receive
any update about this event from netlink/kernel.


You might be able to hook into dhclient.

See /usr/share/doc/dhcp-client/README.dhclient.d



pgpqKwzAhIhVB.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

[Sam Varshavchik]

Tomasz Kłoczko writes:

-- after only 3-4h on m primary desktop I've been able to collect descent  
number of core files




# ls -la /var/lib/systemd/coredump/*
-rw-r-+ 1 root root 1628938240 Feb  6 03:28  
/var/lib/systemd/coredump/core.chrome. 
1000.9b34b2ba89514d86a302484519bf2a53.14303.151788763700
-rw-r-+ 1 root root   37933056 Feb  6 04:10  
/var/lib/systemd/coredump/core.mission-control. 
1000.ad37f99486c24da58887b80804c84322.9243.151789023300


-rw-r-+ 1 root root   28282880 Feb  6 03:34  
/var/lib/systemd/coredump/core.xfce4-notifyd. 
1000.ad37f99486c24da58887b80804c84322.2398.151788803900


-rw-r-+ 1 root root   32505856 Feb  6 04:27  
/var/lib/systemd/coredump/core.xfce4-notifyd. 
1000.ad37f99486c24da58887b80804c84322.5645.151789125800


Never had xfce4-notifyd crash on me. Not sure what mission-control is. I  
have chrome running on my Ubuntu laptop, also XFCE desktop, never had it  
crash either.




pgp7XJSqwqUAh.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: gnome crashes after today upgrade

[Sam Varshavchik]

Tomasz Kłoczko writes:

On 3 February 2018 at 22:55, Richard Shaw  
<hobbes1...@gmail.com> wrote:


   Any news on the cause? I'm waiting to update until this is figured out...

Still don't see any update about the issue.
It is really pain in the a*s that Linux still has no good support to handle


One option that's available to you is to switch to another desktop. No  
issues here, whatsoever, on my XFCE desktop.


I replaced Gnome with XFCE on all my desktops a number of years ago, and  
haven't looked back.


pgpUl344AnHyE.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Firefox "Looking Glass" fiasco

[Sam Varshavchik]

Gerald B. Cox writes:

Everyone makes mistakes - this wasn't the first by Mozilla and won't be the  
last.  I don't believe
they are acting out of malice.  As long as they admit and correct mistakes as  
they go along

that is fine with me.


Here's the most complete statement from Mozilla that I could find regarding  
this:




"Our goal with the custom experience we created with Mr. Robot was to engage  
our users in a fun and unique way," Mozilla's chief marketing officer,  
Jascha Kaykas-Wolff, told Gizmodo. "Real engagement also means listening to  
feedback. And so while the web extension/add-on that was sent out to Firefox  
users never collected any data, and had to be explicitly enabled by users  
playing the game before it would affect any web content, we heard from some  
of our users that the experience we created caused confusion."


"As a result we will be moving the Looking Glass Add-on to our Add-On store  
within the next 24 hours so Mr. Robot fans can continue to solve the puzzle  
and the source can be viewed in a public repository," Kaykas-Wolff added.




Can you point out to me which part indicates that Mozilla admits that  
they made a mistake. Sounds to me like they're just blaming the dumb users  
for not understanding how wonderful was "the experience [they] created".


Does anyone read this as Mozilla admitting that they messed up?



pgpaDMipRPWer.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

stg.pagure.io SSL cert error

[Sam Varshavchik]

While browsing around a sandbox project on stg.pagure.io, the release folder  
URL goes to https://releases.stg.pagure.org


Firefox refuses open it because the server's SSL cert does not include this  
particular domain. Furthermore Firefox refuses to add an exception because  
of HSTS.


Where should this be reported to. Poking around I couldn't find the  
appropriate bug reporting channel...


pgpkzeQFe71U0.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora 27 is here

[Sam Varshavchik]

Josh Boyer writes:


On Wed, Nov 15, 2017 at 5:03 PM, Nicolas Chauvet  wrote:
> 2017-11-15 23:02 GMT+01:00 Nicolas Chauvet :
>> Hi,
>>
>> Just want to say welcome to Fedora 27 !
>>
>> The RPM Fusion repository is ready to server f27 content in time for
>> the release. However, there are few packages that were broken in the
>> process. The ones I'm aware are currently fixed and been pushed in the
>> updates repos. I plan to fixup the GA repo before this week-end to
>> avoid any issue.
>>
>> Thx for the work done.
>
> Oops, sorry, was meant for our own devel list.

A thank you to you and the RPM Fusion team anyway!


Seconded. RPM Fusion is absolutely essential, and very much appreciated.




pgpB6jSF8UyKa.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[Sam Varshavchik]

Jonny Heggheim writes:


On 11/01/2017 11:51 PM, Sam Varshavchik wrote:

> I don't think much of expiring either. But keys for prior releases
> should simply be removed, as part of the upgrade process, or on the
> first boot after a successfull upgrade.
>
> Now, if we go this way, we have to make sure we don't turn a bad
> situation into worse one. It's possible that a botched upgrade might
> end up with a system that's still bootable, so prior releases pgp keys
> should be left alone until it's known that fedup did its job
> successfully.
>
> But once an upgrade is complete, prior release's pgp keys have
> absolutely no value in them, whatsoever, except as an additional
> potential compromise vector.

Packages that was built for older releases are still distributed and
used in newer versions.


So? They're simply signed by the newer release's PGP key. Big deal.



Example:
A package built for Fedora 24, signed with the Fedora 25 key, running on
my Fedora 26 setup.

$ gpg2 < /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-25-primary
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
pub   rsa4096 2016-03-31 [SCE]
  C437DCCD558A66A37D6F43724089D8F2FDB19C98
uid   Fedora 25 Primary (25) <fedora-25-prim...@fedoraproject.org>

$ rpm -qi maven-shared-io
Name    : maven-shared-io
Epoch   : 1
Version : 3.0.0
Release : 2.fc24
Architecture: noarch
Install Date: Sat 29 Oct 2016 12:26:04 AM CEST

 ==

Fedora 26 did not exist in October 2016. As such, it would be logically  
impossible for this package to have been installed from the Fedora 26  
repository. You installed this package when you were running Fedora 25.


And removing Fedora 24/25th PGP key should have no effect, whatsoever, on  
currently-installed packages. PGP keys are checked only when a package gets  
installed. Once installed, nothing really cares about PGP signatures, and it  
wouldn't always be possible to verify it anyway, since config files  
installed by the package could obviously be changed, filestamps could be  
changed, etc…


I do see that maven-shared-io-3.0.0-2.fc24.src.rpm is, apparently, in the  
Fedora 26 repository:


[mrsam@thinkpad tmp]$ dnf download maven-shared-io
Last metadata expiration check: 0:00:00 ago on Wed 01 Nov 2017 08:33:50 PM EDT.
maven-shared-io-3.0.0-2.fc24.noarch.rpm 143 kB/s |  50 kB 00:00
[mrsam@thinkpad tmp]$ rpm --checksig maven-shared-io-3.0.0-2.fc24.noarch.rpm
maven-shared-io-3.0.0-2.fc24.noarch.rpm: rsa sha1 (md5) pgp md5 OK

I have only Fedora 26 PGP keys installed:

[mrsam@thinkpad tmp]$ rpm -qa gpg-pubkey
gpg-pubkey-3276f4b3-582f2526
gpg-pubkey-64dab85d-57d33e22
gpg-pubkey-9690e4af-582f231f

You can confirm, yourself, that these are Fedora and RPM fusion 26 keys.

I would not be able to verify the pgp signature on this package, unless it's  
signed by one of the keys I have installed.


Therefore, the Fedora 26 repo must be carrying this package signed by the  
Fedora 26 PGP key. Otherwise I could not possibly install it, obviously.


For final proof, you can download this package from the Fedora 24, 25, and  
26 repos, separately, and verify that they're not binary identical, because  
each package carries a different PGP signature inside it. But this can be  
someone else's homework assignment. IIRC, the PGP signature is at the tail  
end of the rpm file, so I expect the actual binary files to be binary- 
identical until the last dozen, or so bytes. I don't know if rpm file format  
supports multiple signatures, and whether a new signature replaces the rpm  
file's existig one, or adds to it, and I'm too lazy to check right now. If  
the file sizes are different, it must mean that the F25/F26 sigs were tacked  
onto this package. If the file sizes are identical, it means that a new  
signature replaces the existing one.


Either way, removing old Fedora PGP keys should have absolutely zero impact.



pgpU0vrvWnb57.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Remove old GPG keys?

[Sam Varshavchik]

Kevin Fenzi writes:


I personally don't see much advantage in expiring old keys or the like.
The only attack vector I can see is tricking someone into installing a
package from an EOL release with a known vulnerablity, but if you can do
that you likely can get them to just download it and install it or
download your resigned package and have them accept the key or any
number of things.


I don't think much of expiring either. But keys for prior releases should  
simply be removed, as part of the upgrade process, or on the first boot  
after a successfull upgrade.


Now, if we go this way, we have to make sure we don't turn a bad situation  
into worse one. It's possible that a botched upgrade might end up with a  
system that's still bootable, so prior releases pgp keys should be left  
alone until it's known that fedup did its job successfully.


But once an upgrade is complete, prior release's pgp keys have absolutely no  
value in them, whatsoever, except as an additional potential compromise  
vector.




pgpYk1hNk4uB3.pgp
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org