date:20240402

Kevin Fenzi wrote:
> Why not the opposite:
> 
> Download Workstation
> 
> [I'm a linux user and know what I want, just show me the full list of
> downloads, click here]?

Because that still leads people to click that "Download Workstation" link 
before even seeing the options. "I do not want to have to choose" should be 
a concious choice, also considering that the mostly unconfigurable (by 
design) GNOME is very likely to be the wrong option for anybody not in that 
category. And besides:

> (Which is pretty much what we have now)

Well, not quite, it is more like:

[LOGO Workstation (Download Now) (Learn More)]

[LOGO Server (Download Now) (Learn More)]

[LOGO IoT (Download Now) (Learn More)]

[LOGO Cloud (Download Now) (Learn More)]

[LOGO CoreOS (Download Now) (Learn More)]

Want more Fedora options?

Atomic Desktops (Learn More) ← no frame nor logo nor mention of "download"

Fedora Spins (Learn More) ← no frame nor logo nor mention of "download"

Fedora Labs (Learn More) ← no frame nor logo nor mention of "download"

Fedora ALT Downloads (Learn More) ← no frame nor logo

So you get offered a lot of (most likely) irrelevant (to you) options 
(Server, IoT, Cloud, CoreOS) before even being told that there are more 
options than those (and Workstation), the "Workstation" link does not tell 
you that (even though those are clearly workstation/desktop-targeted options 
too), and you also do not see the full list of options anywhere, but just a 
list of lists. You actually have to click on "Learn More" after "Fedora 
Spins" to even see what desktop environments are available.

Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Adam Williamson wrote:
> I mean, we really don't need to speculate about this much. We did an
> entire overhaul of the project - Fedora.next

That was for Fedora 21 in 2014! As you stated it, I know you and I have been 
around forever and 2014 feels like yesterday, but it was really quite a long 
time ago. ;-)

Now we are planning for Fedora 2*21, which would be a good time to revisit 
this decision.

> which was explicitly based around making it much more focused and less of
> a choose-your-own-adventure, specifically including making the download
> page much more opinionated.

Which is exactly what we (KDE users) are complaining about and have been 
complaining about for those 10 years. And we know many users have complained 
about it, too. If they even found out Fedora supports KDE/Plasma at all, 
which not all of them did.

The download page now is not as horrible as it was 10 years ago, but the 
main issue (the featuring of the Editions at the expense of everything else, 
making the GNOME "Workstation Edition" much more prominent than the other 
desktop environment options) is by design and thus still present.

> AFAIR, the numbers Matthew tracks strongly indicate this was associated
> with a very significant immediate bump in Fedora usage.

There is no evidence that this was a consequence of the change itself and 
not of the massive marketing done around it. Media loves announcing when 
something changes. So if Fedora changes things again to make Editions and 
Spins equal, and comes up with a fancy codename (like the old "Fedora.next") 
for that ("Fedora.equality"? "Fedora.flexible"? "Fedora.choice"? "Your 
Fedora"? Or whatever the marketers can come up with), I expect that we will 
get lots of media coverage and another bump in downloads from that.

Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Steve Cossette wrote:
> Sorry, that's pretty much how things are right now, is that what you were
> trying to demonstrate?
> 
> I'm not really following.

Not really. The current design is better than those old designs that 
immediately served you an ISO when you clicked "Download now", but the focus 
is still on the Editions (which are framed and have logos) at the expense of 
the Spins and the other options (which have neither frames nor logos). 
Clicking on Workstation then gives you a selection of architectures, but not 
of desktop environments; for those, you have to find and pick the (much less 
prominent) Spins option on the front page instead.

I think the first thing to offer users should be the Spins (including the 
"Workstation Edition" which is technically no different from a Spin). Most 
users are looking for a desktop distribution. The non-desktop options should 
come last, after all the desktop-ish (desktop, mobile, lab, and atomic) 
options.

Fedora 21 has introduced the Editions vs. Spins distinction, Fedora 2*21=42 
would be a good time to retire it.

And selecting a desktop/workstation download should require you to select 
the desktop environment, with a skip option clearly labeled something like 
"I do not want to choose" or "Options confuse me" (or "I HATE OPTIONS!" as I 
had called it somewhat hyperbolically), which happens to be a pretty good 
description of the GNOME design philosophy. Or maybe even just:
(·) GNOME (default)
A desktop environment focused on ease of use
**Pick this option if questions like this one confuse you.**
( ) KDE Plasma Desktop
A highly customizable desktop environment
( ) Xfce
A lightweight desktop environment
etc.
But there should be no link directly to any GNOME Edition/Spin/whatever 
(except Labs, if that specific Lab exists only as a GNOME-based version) 
without a clearly visible selection of desktop environments (which is 
unfortunately what the current "Workstation" link is). (And for Labs, the 
selection should at least visibly state somewhere what desktop environment 
they are based on, an information which some Labs now put in their 
description, requiring an extra click to see it, and some not even there.)

Kevin Kofler
--
___
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

[Bug 2270834] perl-Pod-Weaver-4.020 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Pod-Weaver-4.020-1.fc4 |perl-Pod-Weaver-4.020-1.fc4
   |1   |1
   |perl-Pod-Weaver-4.020-1.fc3 |perl-Pod-Weaver-4.020-1.fc3
   |9   |9
   ||perl-Pod-Weaver-4.020-1.fc3
   ||8



--- Comment #9 from Fedora Update System  ---
FEDORA-2024-3780f7d6ee (perl-Pod-Weaver-4.020-1.fc38) has been pushed to the
Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2270834

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270834%23c9
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

On Wed, Apr 03, 2024 at 02:36:07AM +0200, Kevin Kofler via devel wrote:
> Kevin Fenzi wrote:
> > Ok, thats obvously somewhat tounge in cheek, but if we promote multiple
> > things, we need some way to describe them to uses who might not know the
> > history of things and do it in a quick enough way that they won't decide
> > it's all confusing and go do something else.
> 
> It is actually quite simple:
> 
> Here are your options:



Why not the opposite:

Download Workstation

[I'm a linux user and know what I want, just show me the full list of
downloads, click here]?

(Which is pretty much what we have now)

kevin


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

[Bug 2272636] perl-SDL-2.548-22.fc41 FTBFS with SDL2-2.30.1: t/core_events.t fails: Can't use an undefined value as a subroutine reference during global destruction

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-2024-176c95f1c4 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh
--advisory=FEDORA-2024-176c95f1c4`
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-176c95f1c4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information
on how to test updates.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272636

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272636%23c5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

Sorry, that's pretty much how things are right now, is that what you were
trying to demonstrate?

I'm not really following.

Personally, if we were to promote both KDE and Gnome on the website, I'd
make it dead simple. I really suck at making graphics so I'll try to put it
in text:

I imagine a page, where 60% of the page's vh (Viewpoint height -- the
viewable height on your browser) is used to showcase KDE and Gnome. The
left side would be KDE and the right side would be Gnome (Colors don't
really matter tbh but they should differ enough to outline the difference
between the two)

On each side, you'd have a partial screenshot of what the DE looks like,
maybe with a short youtube video that shows a quick demo and some text
outlining the major points of the DE.

I would also suggests adding a thinner section below to simply point to a
page with "More choices", where you'd see the other spins.



On Tue, Apr 2, 2024 at 8:36 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Kevin Fenzi wrote:
> > Ok, thats obvously somewhat tounge in cheek, but if we promote multiple
> > things, we need some way to describe them to uses who might not know the
> > history of things and do it in a quick enough way that they won't decide
> > it's all confusing and go do something else.
>
> It is actually quite simple:
>
>
> Here are your options:
>
> [I HATE OPTIONS, JUST GIVE ME SOMETHING WITH NO OPTIONS!] (big button) →
> downloads GNOME x86_64
>
> DESKTOP SPINS:
>
> Desktop:
> ( ) GNOME (Workstation)
> ( ) KDE Plasma Desktop
> ( ) Xfce
> etc.
>
> Architecture:
> ( ) x86_64 (64-bit x86/AMD64)
> ( ) aarch64 (64-bit ARM)
> etc.
>
> [DOWNLOAD SELECTED]
>
> MOBILE SPINS:
>
> Mobile Environment:
> ( ) Phosh
> etc.
>
> Architecture:
> ( ) aarch64 (64-bit ARM)
> etc.
>
> [DOWNLOAD SELECTED]
>
> LABS:
>
> Lab:
> ( ) Astronomy
> etc.
>
> Architecture:
> etc.
>
> [DOWNLOAD SELECTED]
>
> ATOMIC DESKTOPS:
>
> Desktop:
> ( ) GNOME (Silverblue)
> ( ) KDE Plasma Desktop (Kinoite)
> ( ) Sway (Atomic)
> ( ) Budgie (Atomic)
>
> Architecture:
> etc.
>
> [DOWNLOAD SELECTED]
>
> OTHER EDITIONS:
>
> Edition:
> ( ) Server
> etc.
>
> Architecture:
> etc.
>
> [DOWNLOAD SELECTED]
>
>
> Of course there is going to be a lot of bikeshedding about the order of
> the
> options. I would put them in that order, because I think desktop spins are
> most likely to be downloaded by a new user, then mobile, then use-case-
> specific labs, then experiments like Atomic, and then non-desktop stuff
> like
> Server. But the most important feature is the "I HATE OPTIONS!" button,
> because it serves exactly the users you think will be confused by the
> options and will give them a desktop environment designed exactly for them.
>
> Kevin Kofler
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

On Tue, 2024-04-02 at 21:15 -0400, Steve Cossette wrote:
> I get your point, Kevin. I would argue though that, if a user is looking to
> use Linux, they probably got a decent idea as to what DE they want to use.
> There are SO MANY LINUX DISTROS! Making a choice between two is
> honestly probably not that jarring imo.

I mean, we really don't need to speculate about this much. We did an
entire overhaul of the project - Fedora.next - which was explicitly
based around making it much more focused and less of a choose-your-own-
adventure, specifically including making the download page much more
opinionated. AFAIR, the numbers Matthew tracks strongly indicate this
was associated with a very significant immediate bump in Fedora usage.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

[Bug 2270834] perl-Pod-Weaver-4.020 is available

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version|perl-Pod-Weaver-4.020-1.fc4 |perl-Pod-Weaver-4.020-1.fc4
   |1   |1
   ||perl-Pod-Weaver-4.020-1.fc3
   ||9
Last Closed||2024-04-03 01:15:44



--- Comment #8 from Fedora Update System  ---
FEDORA-2024-13e8e62b59 (perl-Pod-Weaver-4.020-1.fc39) has been pushed to the
Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2270834

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202270834%23c8
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2269439] perl-HTML-Parser-3.82 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-HTML-Parser-3.82-1.fc4 |perl-HTML-Parser-3.82-1.fc4
   |1   |1
   |perl-HTML-Parser-3.82-1.fc4 |perl-HTML-Parser-3.82-1.fc4
   |0   |0
   ||perl-HTML-Parser-3.82-1.fc3
   ||9



--- Comment #8 from Fedora Update System  ---
FEDORA-2024-f9685bc9ea (perl-HTML-Parser-3.82-1.fc39) has been pushed to the
Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2269439

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202269439%23c8
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

I get your point, Kevin. I would argue though that, if a user is looking to
use Linux, they probably got a decent idea as to what DE they want to use.
There are SO MANY LINUX DISTROS! Making a choice between two is
honestly probably not that jarring imo.

On Tue, Apr 2, 2024 at 7:49 PM Kevin Fenzi  wrote:

> On Tue, Apr 02, 2024 at 04:06:45PM -0400, Steve Cossette wrote:
> > Alright, so a substantial amount of information changed since the
> original
> > submission of the change proposal. We aren't necessarily thinking of
> > demoting Gnome. The overall spirit of the CP is that we think KDE, and to
> > some extent the other spins too, need a bit more visibility on the
> website.
> > At the very least, Gnome and KDE should be up front on the frontpage.
>
> So, I am far from a web designer, but if you aren't a Linux savvy person
> and just decided to try out this Fedora thing because you heard it was
> nice and you go to download it and get:
>
> our website: Want a workstation?
> user: yes!
>
> our website: great! We have Gnome and KDE!
> user: what? what does that mean? which one should I get?
>
> our website:
>
> Gnome: "Get things done with ease, comfort, and control.
> An easy and elegant way to use your computer,
> GNOME is designed to help you have the best possible computing experience."
>
> KDE: "Powerful, multi-platform, and for everyone
> Use KDE software to surf the web, keep in touch with colleagues, friends
> and family, manage your files, enjoy music and videos; and get creative
> and productive at work. The KDE community develops and maintains more
> than 200 applications which run on any Linux desktop, and often other
> platforms too."
>
> User: ok, that didn't tell me much, whats the difference?
> perhaps I will just keep using windows.
>
> Ok, thats obvously somewhat tounge in cheek, but if we promote multiple
> things, we need some way to describe them to uses who might not know the
> history of things and do it in a quick enough way that they won't decide
> it's all confusing and go do something else.
>
> kevin
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

Kevin Fenzi wrote:
> Ok, thats obvously somewhat tounge in cheek, but if we promote multiple
> things, we need some way to describe them to uses who might not know the
> history of things and do it in a quick enough way that they won't decide
> it's all confusing and go do something else.

It is actually quite simple:

Here are your options:

[I HATE OPTIONS, JUST GIVE ME SOMETHING WITH NO OPTIONS!] (big button) → 
downloads GNOME x86_64

DESKTOP SPINS:

Desktop:
( ) GNOME (Workstation)
( ) KDE Plasma Desktop
( ) Xfce
etc.

Architecture:
( ) x86_64 (64-bit x86/AMD64)
( ) aarch64 (64-bit ARM)
etc.

[DOWNLOAD SELECTED]

MOBILE SPINS:

Mobile Environment:
( ) Phosh
etc.

Architecture:
( ) aarch64 (64-bit ARM)
etc.

[DOWNLOAD SELECTED]

LABS:

Lab:
( ) Astronomy
etc.

Architecture:
etc.

[DOWNLOAD SELECTED]

ATOMIC DESKTOPS:

Desktop:
( ) GNOME (Silverblue)
( ) KDE Plasma Desktop (Kinoite)
( ) Sway (Atomic)
( ) Budgie (Atomic)

Architecture:
etc.

[DOWNLOAD SELECTED]

OTHER EDITIONS:

Edition:
( ) Server
etc.

Architecture:
etc.

[DOWNLOAD SELECTED]

Of course there is going to be a lot of bikeshedding about the order of the 
options. I would put them in that order, because I think desktop spins are 
most likely to be downloaded by a new user, then mobile, then use-case-
specific labs, then experiments like Atomic, and then non-desktop stuff like 
Server. But the most important feature is the "I HATE OPTIONS!" button, 
because it serves exactly the users you think will be confused by the 
options and will give them a desktop environment designed exactly for them.

Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-02 Thread Kilian Hanich via devel


Am 03.04.24 um 01:48 schrieb Kevin Fenzi:

On Tue, Apr 02, 2024 at 04:06:45PM -0400, Steve Cossette wrote:

Alright, so a substantial amount of information changed since the original
submission of the change proposal. We aren't necessarily thinking of
demoting Gnome. The overall spirit of the CP is that we think KDE, and to
some extent the other spins too, need a bit more visibility on the website.
At the very least, Gnome and KDE should be up front on the frontpage.


So, I am far from a web designer, but if you aren't a Linux savvy person
and just decided to try out this Fedora thing because you heard it was
nice and you go to download it and get:


Quite frankly, considering the goals and the philosophy of Fedora
(always trying to push for new stuff even if it isn't fully ready yet),
I would argue that Fedora isn't for Linux savvy people.


Kilian
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

On Tue, Apr 02, 2024 at 04:06:45PM -0400, Steve Cossette wrote:
> Alright, so a substantial amount of information changed since the original
> submission of the change proposal. We aren't necessarily thinking of
> demoting Gnome. The overall spirit of the CP is that we think KDE, and to
> some extent the other spins too, need a bit more visibility on the website.
> At the very least, Gnome and KDE should be up front on the frontpage.

So, I am far from a web designer, but if you aren't a Linux savvy person
and just decided to try out this Fedora thing because you heard it was
nice and you go to download it and get:

our website: Want a workstation?
user: yes!

our website: great! We have Gnome and KDE!
user: what? what does that mean? which one should I get?

our website: 

Gnome: "Get things done with ease, comfort, and control.
An easy and elegant way to use your computer,
GNOME is designed to help you have the best possible computing experience."

KDE: "Powerful, multi-platform, and for everyone
Use KDE software to surf the web, keep in touch with colleagues, friends
and family, manage your files, enjoy music and videos; and get creative
and productive at work. The KDE community develops and maintains more
than 200 applications which run on any Linux desktop, and often other
platforms too."

User: ok, that didn't tell me much, whats the difference? 
perhaps I will just keep using windows. 

Ok, thats obvously somewhat tounge in cheek, but if we promote multiple
things, we need some way to describe them to uses who might not know the
history of things and do it in a quick enough way that they won't decide
it's all confusing and go do something else. 

kevin

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

On Tue, Apr 02, 2024 at 04:38:25PM -0400, Stephen Gallagher wrote:
> On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette  wrote:
> >
> > I personally would very much agree with enforcing the use of 2fa on the 
> > Fedora Account System. Maybe take that opportunity to make it a bit more 
> > user friendly? (Such as the fkinit prompt requiring the 2fa code being 
> > added at the end of your password -- to be clear I think the 2fa code 
> > should be separate)
> 
> https://pagure.io/fedora-packager/pull-request/179

I agree that fixing the mismatch in prompts might be nice, but why does
having 2fa seperate make things any better? I mean, it's one more return
you get to hit. ;)

And... I am not sure about moving the handling of passwords to a bash
script from a kinit prompt.

kevin


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

2024-04-02 Thread Gordon Messmer


On 2024-03-30 11:52, Dmitry Belyavskiy wrote:


We have an upstream-adjusted version of this patch, see 
https://bugzilla.mindrot.org/show_bug.cgi?id=2641
I'm OK to bring the updated version of this script to Fedora as soon 
as it is finalized.



I proposed https://src.fedoraproject.org/rpms/openssh/pull-request/72 , 
which uses the implementation from 
https://www.freedesktop.org/software/systemd/man/devel/sd_notify.html#Notes
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Steve Cossette wrote:
> We essentially just want more visibility on the website, if that makes
> sense.

Back when I was still a KDE SIG member, whenever we brought that up with the 
Websites Team, they would just point us to the Board (what is now the 
Council), and the Board would point us back to the Websites Team. That 
fingerpointing was very effective at preventing any change.

And the Websites Team has always been really creative at hiding the KDE Spin 
the best they could, hiding it behind extra "Additional options" links in 
fine print, even with a grayed-out "Spins" icon (looking as if they were 
somehow unavailable), while having a huge "Download" button on the front 
page immediately serving you a GNOME ISO for a default architecture (for a 
long time i686 even though many people already actually wanted x86_64, then 
x86_64 even while 32-bit was still supported) with no further confirmation. 
Any reasonable Free Software project does not have the download link on the 
front page serve directly an arbitrary file, but a download page with 
explanations and a choice of download options, but the Fedora Websites Team 
insisted that "'Download' means 'Download'" and that a button with a verb 
must trigger an immediate action.

Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Adam Williamson wrote:
> Change proposals can be, and frequently are, rejected.

If you look at the statistics, they very rarely are. A lot of bad changes 
with lots of criticism on the mailing list were waved through by FESCo. But 
if they dare touching a Red Hat holy cow such as the dogma of defaulting to 
GNOME everywhere, they are likely to be rejected. (Been there, done that.)

Kevin Kofler
--
___
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

Richard W.M. Jones wrote:
> Yes, in this case the attacker had set the serial number to 30, but
> the latest upstream serial number was 3.  autoreconf won't replace the
> file in this case unless it is deleted.  There really should be an
> "always replace if you can" option in autoreconf.

Is that not what -f is supposed to do? At least, the documentation claims 
so, but the implementation does not actually do what is documented.

Kevin Kofler
--
___
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: What we mean when we talk about "supply chains" [was Re: Three steps we could take to make supply chain attacks a bit harder]

Gary Buhrmaster wrote:
> And, more importantly, the industry has agreed
> to use the term supply chain.  Is the term
> perhaps overloaded, or perhaps too
> ill-defined/imprecise?  Sure.  But if one wants
> to use a different term one would need to work
> across the industry to change the term, and
> that is not going to happen.

Well, one could argue that Free Software is a community, not an industry, so 
"the industry" cannot agree on anything, and "supply chain" as an industrial 
term obviously does not apply. And also that it is called "Free Software" 
and not "Open Source". :-)

Kevin Kofler
--
___
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

On Wed, 2024-04-03 at 00:15 +0200, Kevin Kofler via devel wrote:
> Adam Williamson wrote:
> > It occurs to me - maybe you don't agree, but this is how it looks to me
> > - that, ironically, you and I usually argue the exact *opposite* side
> > of this case, no? I argue in *favor* of somewhat-arbitrary delays to
> > packages appearing in 'stable', and you argue *against* them. :D
> 
> I have never argued against updates-testing existing or that all packages 
> should skip updates-testing. "Please pick up this new upstream version, it 
> has some great new features" as was done here is exactly the kind of changes 
> that SHOULD go through updates-testing. But if the maintainer has something 
> urgent to push out, such as an important regression fix or a critical 
> security fix (e.g., a fix for a backdoor like this one), they should be 
> allowed to decide to skip testing and not be treated as being too 
> incompetent for that (while at the same time allowing any other person, with 
> no other credentials than a FAS account, to +1 the package, allowing it to 
> be autopushed to stable – everyone except the one person most qualified to 
> make that decision). THAT is what I have been arguing for all this time, and 
> I do not see how this contradicts my position here in any way.

Fair enough. I think the rest of my post stands, though, as it was more
about my argument than yours.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Adam Williamson wrote:
> It occurs to me - maybe you don't agree, but this is how it looks to me
> - that, ironically, you and I usually argue the exact *opposite* side
> of this case, no? I argue in *favor* of somewhat-arbitrary delays to
> packages appearing in 'stable', and you argue *against* them. :D

I have never argued against updates-testing existing or that all packages 
should skip updates-testing. "Please pick up this new upstream version, it 
has some great new features" as was done here is exactly the kind of changes 
that SHOULD go through updates-testing. But if the maintainer has something 
urgent to push out, such as an important regression fix or a critical 
security fix (e.g., a fix for a backdoor like this one), they should be 
allowed to decide to skip testing and not be treated as being too 
incompetent for that (while at the same time allowing any other person, with 
no other credentials than a FAS account, to +1 the package, allowing it to 
be autopushed to stable – everyone except the one person most qualified to 
make that decision). THAT is what I have been arguing for all this time, and 
I do not see how this contradicts my position here in any way.

Kevin Kofler
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-02 Thread Sergio Belkin

>
> it’s not a change.
> --
> --
> Sergio Belkin
> LPIC-2 Certified - http://www.lpi.org
>

It's not a change already decided I meant :) !

sorry for the noise
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Oooo I could go for some Yak meat!

On Tue, Apr 2, 2024 at 5:32 PM Adam Williamson 
wrote:

> On Tue, 2024-04-02 at 17:37 -0300, Sergio Belkin wrote:
> >
> > I am a happy KDE user, since the good old days of version 1.0. I
> celebrate
> > this decision! My recognition goes to the enormous and sustained work of
> > the entire KDE community.
> > Cheers,
> > Sergiio
>
> To be clear, there is no 'decision'. This is a Change proposal. Any
> Fedora community member can submit a Change proposal proposing just
> about any change; I could submit one tomorrow proposing we abandon all
> software development and open a yak farm instead.
>
> A Change proposal existing is in no way an indication of any ultimate
> outcome. Change proposals can be, and frequently are, rejected.
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-02 Thread Sergio Belkin

El mar, 2 abr 2024 a las 18:32, Adam Williamson ()
escribió:

> On Tue, 2024-04-02 at 17:37 -0300, Sergio Belkin wrote:
> >
> > I am a happy KDE user, since the good old days of version 1.0. I
> celebrate
> > this decision! My recognition goes to the enormous and sustained work of
> > the entire KDE community.
> > Cheers,
> > Sergiio
>
> To be clear, there is no 'decision'. This is a Change proposal. Any
> Fedora community member can submit a Change proposal proposing just
> about any change; I could submit one tomorrow proposing we abandon all
> software development and open a  instead.
>
> A Change proposal existing is in no way an indication of any ultimate
> outcome. Change proposals can be, and frequently are, rejected.
> --
> Adam Williamson (he/him/his)
> Fedora QA
> Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
> https://www.happyassassin.net
>
>
>
> --
> ___
> 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
>



Oh, yup Adam, thank you for correcting it. Haha, the yak farm comment made
me laugh. I jumped the gun; it’s not a change. Nevertheless, I’m glad this
topic is being discussed in a healthy manner :) In fact, on this page, we
can also check the change policy and join the discussion thread!”
-- 
--
Sergio Belkin
LPIC-2 Certified - http://www.lpi.org
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

On Tue, 2024-04-02 at 17:37 -0300, Sergio Belkin wrote:
> 
> I am a happy KDE user, since the good old days of version 1.0. I celebrate
> this decision! My recognition goes to the enormous and sustained work of
> the entire KDE community.
> Cheers,
> Sergiio

To be clear, there is no 'decision'. This is a Change proposal. Any
Fedora community member can submit a Change proposal proposing just
about any change; I could submit one tomorrow proposing we abandon all
software development and open a yak farm instead.

A Change proposal existing is in no way an indication of any ultimate
outcome. Change proposals can be, and frequently are, rejected.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

Gordon Messmer wrote:
> Purely as trivia, and as I haven't seen it discussed elsewhere, the
> malware steals a different set of symbols on Fedora, where
> RSA_public_decrypt doesn't seem to appear in the GOT at all.

This proves again that this is a very targeted attack that carefully 
analyzed the individual targeted distributions, the distributions whose 
packaging tools the build script attempts to detect were not just picked 
because they are known to link OpenSSH to liblzma, but also individually 
tested and targeted.

Kevin Kofler
--
___
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

2024-04-02 Thread Stephen Gallagher

On Tue, Apr 2, 2024 at 3:55 PM Steve Cossette  wrote:
>
> I personally would very much agree with enforcing the use of 2fa on the 
> Fedora Account System. Maybe take that opportunity to make it a bit more user 
> friendly? (Such as the fkinit prompt requiring the 2fa code being added at 
> the end of your password -- to be clear I think the 2fa code should be 
> separate)

https://pagure.io/fedora-packager/pull-request/179
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-02 Thread Sergio Belkin

El mar, 2 abr 2024 a las 6:40, Aoife Moloney ()
escribió:

> Wiki - https://fedoraproject.org/wiki/Changes/FedoraPlasmaWorkstation
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> Switch the default desktop experience for Workstation to KDE Plasma.
> The GNOME desktop is moved to a separate spin / edition, retaining
> release-blocking status.
>
> == Owner ==
>
> * Names: [[User:joshstrobl | Joshua Strobl]], [[User:marcdeop | Marc
> Deop i Argemí]], [[User:tdawson | Troy Dawson]], [[User:farchord |
> Steve Cossette]], [[User:aleasto| Alessandro Astone]]
> * Emails: jos...@buddiesofbudgie.org, marcd...@fedoraproject.org,
> tdaw...@redhat.com, farch...@gmail.com, alea...@fedoraproject.org
>
> == Detailed Description ==
>
> With the release of Plasma 6, KDE Plasma has developed into a high
> quality, well-regarded desktop experience.
>
> === Improved end user experience ===
>
> Plasma has been at the forefront of creating a cohesive desktop
> platform that empowers the user to have full ownership of their
> computing experience.
>
> Plasma provides this approachable, highly-flexible, user-extensible
> experience with predictability across Plasma releases. Unlike other
> desktop experiences such as GNOME Shell, the APIs leveraged by Plasma
> applets / widgets have been more stable across “minor” Plasma
> releases, reducing long-term user frustration and promoting a
> healthier ecosystem for developers and users alike.
>
> This extensibility additionally applies to the underlying window
> manager, KWin, with effects and scripts that provide both utility and
> personalization, such as:
>
> * Automatically blocking compositing for full screen applications
> * Fun effects such as window glitch and portals
>
> Plasma provides a more traditional user experience that could be
> viewed as being more approachable to everyday computing users, serving
> as a smoother "on-ramp" to using Linux-based operating systems.
> Alongside its wide breadth of personalization capabilities, it
> provides an out-of-the-box desktop experience that is more predictable
> than some of its counterparts. As an example, Plasma provides a system
> tray for applications supporting StatusNotifierItem (e.g. Flameshot,
> OBS Studio, VPN clients), which is not functionality supported by
> default in GNOME Shell and requires an extension which may break
> between releases.
>
> === Standardization support ===
>
> The KDE community has a long heritage of collaborative standards
> development and supporting capabilities that application developers
> and users need for a productive experience.
>
> KDE is heavily involved in the development of cross-desktop standards
> and tools that benefit the larger open source desktop community. From
> the XDG icon theme specification to D-Bus to StatusNotifierItems and
> Wayland protocols, KDE has been front and center for evolving the
> Linux desktop platform in a manner that benefits the wider community.
>
> Many of the specifications and protocols in use today originate or are
> heavily influenced by KDE, and KDE has continued to be a bastion of
> innovation in a user-centric and community-centric manner.
>
> Notably, the following recent Wayland protocols have been driven or
> influenced by KDE:
>
> * xdg-toplevel-drag (dragging tabs in and out of windows)
> * content-type
> * drm-lease (enable applications to selectively gain privileged
> display device access)
> * tearing-control (enable faster than display framerate refreshing, ie
> no “vsync lock”)
> * ext-idle-notify
> * xdg-activation (enable notifications to bring a window to the
> foreground on user activation)
> * xdg-decoration (server side decorations, derived from KDE’s protocol)
>
> There are several upcoming protocols being driven by KDE as well, such as:
>
> * alpha-modifier (set alpha values for a surface)
> * ext-blur (enable blur effect underneath a surface)
> * xdg-toplevel-icon (enable applications to set window icons)
> * ext-placement (allow application window positioning)
> * window-id (consistent, uniform method window IDs)
> * xdg-pip (picture in picture overlays)
> * dbus-annotation (link D-Bus objects to surfaces)
>
> This demonstrates that KDE works not to just enable new technologies
> and features for Plasma Wayland, but they also do it in a way that
> drives larger community adoption, success, and growth.
>
> === Wayland support ===
>
> KDE Plasma offers the most advanced Wayland desktop experience today,
> providing support for highly-demanded features, such as:
>
> * Fractional scaling
> * Color management
> * Variable Refresh Rate for capable displays
> * Support for optionally allowing legacy X11 applications to access
> desktop resources
> * Screensharing for legacy applications
> * Global shortcut

Re: Self Introduction: Matthew Kosarek

2024-04-02 Thread Neal Gompa

On Tue, Apr 2, 2024 at 3:44 PM Matthew Kosarek via devel
 wrote:
>
> Hello all,
>
> My name is Matthew (Matt) Kosarek and I am a developer on the Mir team at 
> Canonical. I am currently developing a tiling window manager based on Mir 
> called miracle-wm (https://github.com/mattkae/miracle-wm). The goal is to 
> have a tiling experience similar to sway/i3, but with a bit more flair by 
> default. I am in the process of packaging the project for Fedora at the 
> moment, which is why I am introducing myself here. Here's a link to the 
> review request for miracle-wm: 
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2272744. Feel free to 
> check out the project and file bugs/feedback if you have any! I am aiming to 
> have release 0.2.0 later this month 
>
> Nice to meet you all,
>

Welcome to Fedora, Matt! I've picked up your package to review. I hope
you have a great time here. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Alright, so a substantial amount of information changed since the original
submission of the change proposal. We aren't necessarily thinking of
demoting Gnome. The overall spirit of the CP is that we think KDE, and to
some extent the other spins too, need a bit more visibility on the website.
At the very least, Gnome and KDE should be up front on the frontpage.

I completely agree that Gnome is an awesome DE, and I will never knock that
down. But I think the KDE audience in the Fedora community is also quite
substantial.

We've been discussing it in Matrix, and we can't seem to reach a
consensus as to what is the best way to initiate the discussion procedure.
Figured a change proposal was probably a decent way to "kick the hornet's
nest", so to speak.

We essentially just want more visibility on the website, if that makes
sense.

On Tue, Apr 2, 2024 at 3:58 PM Steven A. Falco 
wrote:

> On 4/2/24 03:50 PM, Steve Cossette wrote:
> > Well, we did submit this yesterday around 2:30-3:00PM EST, guessing it
> was a bit too late.
> >
> > But the proposal is 1000% serious.
>
> I'm glad to hear you say that, as I switched to KDE around the time of
> Gnome3 and never looked back.
>
> Steve
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Self Introduction: Matthew Kosarek

Hello Matthew, and welcome to Fedora!

You'll find alot of good people in here eager to help you. Feel free to
also drop in on matrix for a more real-time conversation!

On Tue, Apr 2, 2024 at 3:44 PM Matthew Kosarek via devel <
devel@lists.fedoraproject.org> wrote:

> Hello all,
>
> My name is Matthew (Matt) Kosarek and I am a developer on the Mir team at
> Canonical. I am currently developing a tiling window manager based on
> *Mir* called *miracle-wm* (https://github.com/mattkae/miracle-wm). The
> goal is to have a tiling experience similar to *sway*/*i3*, but with a
> bit more flair by default. I am in the process of packaging the project for
> Fedora at the moment, which is why I am introducing myself here. Here's a
> link to the review request for *miracle-wm*:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2272744. Feel free
> to check out the project and file bugs/feedback if you have any! I am
> aiming to have release 0.2.0 later this month 
>
> Nice to meet you all,
>
> Matt
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-02 Thread Steven A. Falco


On 4/2/24 03:50 PM, Steve Cossette wrote:

Well, we did submit this yesterday around 2:30-3:00PM EST, guessing it was a 
bit too late.

But the proposal is 1000% serious.


I'm glad to hear you say that, as I switched to KDE around the time of Gnome3 
and never looked back.

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

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

I personally would very much agree with enforcing the use of 2fa on the
Fedora Account System. Maybe take that opportunity to make it a bit more
user friendly? (Such as the fkinit prompt requiring the 2fa code being
added at the end of your password -- to be clear I think the 2fa code
should be separate)

On Tue, Apr 2, 2024 at 3:06 PM Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Chris Adams wrote:
> > However, it's a good trigger to review Fedora's security approach in
> > general (like 2FA use).
>
> Using such an issue that made it through upstream 2FA and would also have
> made it through any 2FA enforcement in Fedora as an excuse to force 2FA on
> us is just pure nonsense.
>
> Kevin Kofler
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

Well, we did submit this yesterday around 2:30-3:00PM EST, guessing it was
a bit too late.

But the proposal is 1000% serious.

On Tue, Apr 2, 2024 at 3:46 PM Jonathan Wakely  wrote:

> On Tue, 2 Apr 2024 at 19:44, Richard Hughes  wrote:
> >
> > On Tue, 2 Apr 2024 at 10:40, Aoife Moloney  wrote:
> > > Switch the default desktop experience for Workstation to KDE Plasma.
> > > The GNOME desktop is moved to a separate spin / edition, retaining
> > > release-blocking status.
> >
> > If this is an April fools joke -- it's a weird one, and a day too late.
>
> Well it was added to the wiki yesterday, but only picked up by Aoife today.
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-02 Thread Jonathan Wakely

On Tue, 2 Apr 2024 at 19:44, Richard Hughes  wrote:
>
> On Tue, 2 Apr 2024 at 10:40, Aoife Moloney  wrote:
> > Switch the default desktop experience for Workstation to KDE Plasma.
> > The GNOME desktop is moved to a separate spin / edition, retaining
> > release-blocking status.
>
> If this is an April fools joke -- it's a weird one, and a day too late.

Well it was added to the wiki yesterday, but only picked up by Aoife today.
--
___
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

Self Introduction: Matthew Kosarek

2024-04-02 Thread Matthew Kosarek via devel


Hello all,

My name is Matthew (Matt) Kosarek and I am a developer on the Mir team 
at Canonical. I am currently developing a tiling window manager based on 
/Mir/ called *miracle-wm* (https://github.com/mattkae/miracle-wm). The 
goal is to have a tiling experience similar to /sway///i3/, but with a 
bit more flair by default. I am in the process of packaging the project 
for Fedora at the moment, which is why I am introducing myself here. 
Here's a link to the review request for /miracle-wm/: 
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2272744. Feel free 
to check out the project and file bugs/feedback if you have any! I am 
aiming to have release 0.2.0 later this month 


Nice to meet you all,

Matt
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-02 Thread Tomasz Torcz

On Tue, Apr 02, 2024 at 06:44:02PM +, Richard Hughes wrote:
> On Tue, 2 Apr 2024 at 10:40, Aoife Moloney  wrote:
> > Switch the default desktop experience for Workstation to KDE Plasma.
> > The GNOME desktop is moved to a separate spin / edition, retaining
> > release-blocking status.
> 
> If this is an April fools joke -- it's a weird one, and a day too late.

  Why would it be? KDE Plasma seem to be more technically advanced than
GNOME. This change makes sense.

-- 
Tomasz Torcz   There exists no separation between gods and men:
to...@pipebreaker.pl   one blends softly casual into the other.  — Frank 
Herbert
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

On Tue, 2024-04-02 at 21:05 +0200, Kevin Kofler via devel wrote:
> Aoife Moloney wrote:
> > Switch the default desktop experience for Workstation to KDE Plasma.
> > The GNOME desktop is moved to a separate spin / edition, retaining
> > release-blocking status.
> 
> It is funny that the KDE SIG is proposing that now. I have a sense of déjà-
> vu:
> https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default
> 
> Back then, the KDE SIG was NOT willing to support my proposal (even though 
> the timing would have been ideal, given that GNOME was badly hit at the time 
> by the GNOME 3 transition and users disappointed by the radical cuts in 
> customizability). Now they are refloating it as their own, without even 
> citing my original proposal.

Kevin, I know you and I have been around forever and 2011 feels like
yesterday, but it was really quite a long time ago.

Some of the people involved in the proposal didn't even use Fedora in
2011. Heck, there are probably people using Fedora who weren't *born*
in 2011.

If you compare the KDE SIG member list from May 2011 (approx. time of
your old proposal) and the current one, the only people who appear on
both lists are Rex Dieter and Than Ngo, neither of whom is an owner of
this Change proposal.

https://fedoraproject.org/wiki/SIGs/KDE
https://fedoraproject.org/w/index.php?title=SIGs/KDE=239023
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



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

2024-04-02 Thread Gordon Messmer


On 2024-04-02 03:42, Lennart Poettering wrote:

Also, I don't think we should get hung up too much on the libsystemd
thing. I know people like to hit on systemd,



I know, and one of the problems that results from having just a torrent 
of undeserved criticism is that it naturally predisposes the maintainers 
to reflexively disregard all criticism.  To be clear: I *like* systemd.  
One of the things I like about it is that while the project is fairly 
large, the individual functions/services are modular and mostly 
independent of each other.  But that isn't really true of libsystemd.  I 
understand that there are some dependencies between different components 
of libsystemd, but sd-daemon doesn't seem to have any dependencies on 
sd-journal, for example.




but the attacker could
have used various other vehicle libs for their goal, too. I mean, sshd
uses PAM, and that pull in variety of things through its modules



PAM modules aren't a problem for the same reason that the compression 
libraries aren't a problem now that they're dlopen()ed.
--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

Aoife Moloney wrote:
> Switch the default desktop experience for Workstation to KDE Plasma.
> The GNOME desktop is moved to a separate spin / edition, retaining
> release-blocking status.

It is funny that the KDE SIG is proposing that now. I have a sense of déjà-
vu:
https://fedoraproject.org/wiki/Features/KDE_Plasma_Desktop_by_default

Back then, the KDE SIG was NOT willing to support my proposal (even though 
the timing would have been ideal, given that GNOME was badly hit at the time 
by the GNOME 3 transition and users disappointed by the radical cuts in 
customizability). Now they are refloating it as their own, without even 
citing my original proposal.

Kevin Kofler
--
___
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

Chris Adams wrote:
> However, it's a good trigger to review Fedora's security approach in
> general (like 2FA use).

Using such an issue that made it through upstream 2FA and would also have 
made it through any 2FA enforcement in Fedora as an excuse to force 2FA on 
us is just pure nonsense.

Kevin Kofler
--
___
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

Matthew Miller wrote:
> I sometimes see unit test failures. The developer ran the tests, but not
> on S390.

Why would I want a test failure on such an exotic architecture to fail my 
build? The only reason Fedora supports that architecture at all is pressure 
from IBM. Basically nobody uses it.

Kevin Kofler

--
___
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: F42 Change Proposal: Fedora Plasma Workstation (System-Wide)

2024-04-02 Thread Richard Hughes

On Tue, 2 Apr 2024 at 10:40, Aoife Moloney  wrote:
> Switch the default desktop experience for Workstation to KDE Plasma.
> The GNOME desktop is moved to a separate spin / edition, retaining
> release-blocking status.

If this is an April fools joke -- it's a weird one, and a day too late.

Richard.
--
___
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: xz backdoor

Lennart Poettering wrote:
> It *literally* is just sending a text string "READY=1" in an AF_UNIX
> datagram to a socket whose path is provided to you in the
> $NOTIFY_SOCKET env var.

I see so many ways one can get this wrong. E.g., using some abstraction for 
the socket write that can also write to regular files, without checking that 
"$NOTIFY_SOCKET" is really a socket (or checking it with a TOCTOU 
vulnerability), introducing an arbitrary file overwrite vulnerability.

Kevin Kofler
--
___
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

[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Committee

2024-04-02 Thread tdawson

Dear all,

You are kindly invited to the meeting:
   EPEL Steering Committee on 2024-04-03 from 18:00:00 to 19:00:00 UTC
   At fedora-meet...@chat.fedoraproject.org

The meeting will be about:

https://chat.fedoraproject.org/#/room/#meeting:fedoraproject.org

This is the weekly EPEL Steering Committee Meeting.

A general agenda is the following:

#topic aloha

#topic EPEL Issues https://pagure.io/epel/issues
* https://pagure.io/epel/issues?tags=meeting=Open

#topic Old Business (if needed)

#topic General Issues / Open Floor




Source: https://calendar.fedoraproject.org//meeting/10780/

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

Re: xz backdoor

2024-04-02 Thread Petr Menšík


On 02. 04. 24 14:17, Lennart Poettering wrote:

On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote:


I am not convinced dlopen will it make secure in the end. I am not sure this
is a good solution. dlopen makes those dependencies non-obvious from
packaging side and non-visible from ldd or similar checking programs.

I think it should be considered to offer more than one dynamic
library.

It was considered. To the point that a decade ago, libsystemd
originally was split up. But it was awful to maintain.

But let's not repeat this discussion here. Read up here:
https://github.com/systemd/systemd/issues/32028


Oh, I hate the way discussions are moderated at systemd upstream. I 
would prefer to discuss here.


It appears you do not want to make it simple to use just notify lib. But 
luckily it does not have to be maintained by systemd team. Yes, the 
protocol is trivial. But it still needs to handle conditions when it 
does not run under systemd. When it does, but error occurs. While number 
of lines required are very low, it would have need to be duplicated many 
times in many services. More or less the same code.


It is apparent either everyone will implement it themselves or 
systemd-independent project needs to provide just limited sd_notify 
shared library. At least it needs documentation. Indication it 
implements sd_notify in some way is nice to have bonus.



For example most services I maintain links to libsystemd just
because it wants sd_notify calls in their services. Without any
proof I would expect quite many services would have similar
problem. Could be perhaps libsystemd broken into few more dynamic
linked libraries? I somehow doubt any kind of compression is needed
for sd_notify calls.

Could be even smaller library libsystemd-notify linked from libsystemd,
which would allow end applications to explicitly declare they need more
limited set of functions?

Why link? I'd really just suggest people to implement the trivial
client on their own. It's a trivial protocol for a reason: so that
people can implement it natively in their language and framwork
without bothering with our upstream libsystemd.
Because the number of applications solving the same problem is rather 
high. It is not issue to be solved in about 3 projects. There are dozens 
of daemons, which should implement the same functionality. Common base 
even with a tiny library still makes a sense to me. Especially if most 
of them linked unnecessarily to libsystemd and thought that was the best 
option.


use libsystemd if you link against it anways and hack in C, or if you
really don't are about the extra dep for a single function, but
otherwise, why would you use the lib?

It *literally* is just sending a text string "READY=1" in an AF_UNIX
datagram to a socket whose path is provided to you in the
$NOTIFY_SOCKET env var. Anyone with a moderate understanding of UNIX
APIs should be able to hack that up in a a few lines of code. It's a
protocol I can summarize and explain in *one* frickin' sentence.


Yes, I admit, it is simple line oriented protocol. But you need to get 
notify socket path, handle failures when opening it. You need to know 
what to write there, so also documentation is needed. Man page for 
sd_notify is nice. Implementation of sd_notifyf() function would not be 
trivial. While it is not difficult to get right, it does not make sense 
to have over 15 different implementations, when it can share the same 
code. When you want to include also error messages, it certainly becomes 
more than few lines.


Function pid_notify_with_fds_internal from 
./src/libsystemd/sd-daemon/sd-daemon.c certainly is not just few lines, 
as suggested. Should I ask why, if not necessary? It seems whole 
sd-daemon.c has 775 lines, which would be nice to have separate library. 
Things missing are some helpers. Socket activation is not as needed as 
core sd_notify, but might be a good addition. Still needs just 
environment and pointer to ints. No unwanted dependencies, I think that 
would make a nice standalone shared library. It provides everything I 
would need in common service.



sshd upstream understood this btw:

https://bugzilla.mindrot.org/show_bug.cgi?id=2641

Lennart

--
Lennart Poettering, Berlin


I think they preferred having fast fix over having long-term sustainable 
solution. I haven't seen offer to provide libsystemd-notify library with 
minimal dependencies, which they kindly refused. They preferred bundled 
code over systemd bloat in comment #13. I haven't seen bloat-less 
library considered in the bug, but might have missed it?


The question is, how should be the separate library called. 
libsystem_notify? Ideas for a better name?


Compat include header to make it otherwise unmodified with libsystemd 
would be nice as well.


--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
--
___
devel mailing list --

Re: Golang bundled() Provides generator

2024-04-02 Thread Maxwell G

On Tue Apr 2, 2024 at 17:16 +0200, Dan Čermák wrote:
> Hi Maxwell & Go SIG,

Hi Dan,

Thank you for reaching out!

> we have recently started working on introducing a bundled() provides
> generator for golang in openSUSE and found a very simple solution using
> the output of `go version -m /path/to/binary` [1]

It seems that only works when builds are performed with GO111MODULE
turned on[1]. We have it turned off by default, although I suppose we
can turn it on when doing vendored builds—we only need to turn it off
when using the RPM-packaged dependencies for un-vendored packages.
Without GO111MODULE, the dep information doesn't show up with "go
version -m."

[1] https://go.dev/blog/go116-module-changes

> The solution is of course only that simple, because we build more or
> less all go binaries with vendored dependencies and hence we do not need
> to distinguish between those build with vendored and those build
> without.
>
> As I would like to align the Fedora and openSUSE go packaging closer
> together and hence, if possible, find a solution to use this generator
> for both Fedora and openSUSE. I think it is a bit simpler and does not
> require to ship the modules.txt in the final rpm. However, I see that
> both are rather weak reasons.
>
> Do you see a way how we can find a common solution? E.g. by having a
> macro %go_enable_bundled_provides that would set an environment variable
> and enable the bundled generator?

Other than the technical issue with GO111MODULE, I still prefer
modules.txt approach. It is more efficient, as we don't need to process
every single binary file in the package, and it requires explicit opt-in
from the packager.

Best,
Maxwell
--
___
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: Reminder: F40 final freeze starts next week (2024-04-02)

On Tue, 2024-04-02 at 10:22 -0600, Jerry James wrote:
> 
> - We retroactively change the time to stable of all updates that have
> already been submitted.  I might have an update that I think will go
> stable in 1 more day, and suddenly it isn't going to go stable for 5
> more days.

This is a constraint of Bodhi's current implementation. It doesn't keep
a permanent record of what the value was at creation time for each
update, it re-calculates it from the current configured value at
various points, including when you try to do a push.

I think we kinda want this behaviour, but we *could* do a better job of
communicating when it changes, at least. Currently it's rather
confusing if you get caught in the change, because you see the "this
update can be pushed stable" comment as the last thing on the update,
but it actually can't. We *could* detect when this changes and post a
new 'oops, sorry, no it can't any more' comment.
-- 
Adam Williamson (he/him/his)
Fedora QA
Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org
https://www.happyassassin.net



--
___
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: Reminder: F40 final freeze starts next week (2024-04-02)

2024-04-02 Thread Stephen Gallagher

On Tue, Apr 2, 2024 at 12:18 PM Fabio Valentini  wrote:
>
> On Tue, Apr 2, 2024 at 6:08 PM Sandro  wrote:
> >
> > On 26-03-2024 22:15, Adam Williamson wrote:
> > > On Tue, 2024-03-26 at 21:34 +0100, Sandro wrote:
> > >> On 26-03-2024 16:25, Kevin Fenzi wrote:
> > >>> So, please take this time to do any last minute testing and bugfixing
> > >>> and make sure any packages you expect to be in the final f40 base
> > >>> repositories are pushed stable before next Tuesday (2024-04-02).
> > >>
> > >> I was just wondering, and someone else with me, if today's updates would
> > >> still make it in time?
> > >>
> > >> If not, I thank you for the reminder nonetheless, but would also like to
> > >> ask to have it sent in time for updates to still be able to land in the
> > >> release before freeze happens.
> > >>
> > >> Of course, there's always the option of going around begging for
> > >> (instant) karma ...
> > >
> > > You still have a week until next Tuesday, so...yes.
> >
> > We are one week down the road. I've submitted an update a week ago
> > shortly after Adam's reply was sent (March 26, 21:48 UTC). Final freeze
> > is now in effect and the update[1] has *not* made it to stable. It's
> > still in testing.
> >
> > Luckily, this update can wait until after freeze. I'm glad I decided to
> > ask for karma for another update submitted earlier the same day.
> >
> > [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ebd1e2c45
>
> Yes, 7 days between end of beta freeze and start of final freeze is
> not enough to land an update that has autotime=7days. Which is really
> annoying.
> Maybe next time we can make the non-freeze period last like 8-9 days?
> One week (especially if that week contains the Easter holiday) is not
> enough.

For the record, FESCo reviewed a request to extend the non-freeze
period and decided that we would take on the burden of going through
the Freeze Exception approval process rather than extend the
non-Freeze period (which would have necessitated extending the F40
schedule).

These updates are certainly candidates for Freeze Exception
consideration, so please raise them as such via
https://qa.fedoraproject.org/blockerbugs/propose_bug
--
___
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: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

2024-04-02 Thread Dmitry Belyavskiy

Dear Gary,

On Tue, Apr 2, 2024 at 5:39 PM Gary Buhrmaster 
wrote:

> On Tue, Apr 2, 2024 at 3:12 PM Dmitry Belyavskiy 
> wrote:
>
> > Third-party engines may be a problem but as we don't break ABI, it's not
> a problem of the moment.
>
> The fact you are removing the headers means it is
> a problem for 3rd party engines who build from
> source (and everyone should at least occasionally
> be building from source as part of their CI).
>
> I consider removing the headers as breaking
> the API, as the headers define the API.
>

I agree with moving the engine header package to a separate devel package
instead of removing it.


> The headers already mark the engine APIs
> as deprecated.  Orgs with resources should
> be starting their migration, although some
> will defer it to the next quarter (and the
> next)
>

Yes. That's why I think the pressure in this direction is worth the effort.

I believe this should be part of OpenSSL 4.0.
> It will be a clear change.  There is no
> compelling reason for this to happen
> today via the headers.  Instead this should
> be a marketing campaign by OpenSSL
> to remind everyone that engines are
> going away with OpenSSL 4.0 with every
> new set of release notes (first item,
> in double bold), and that orgs need to
> start their migration.  And then do it again.
>  And then do it again.  And when OpenSSL
> 4.0 is released, you can remind everyone
> you warned them.


I agree that removing the engine stuff is clearly 4.0 stuff (or earlier
version if .so version changes).
But there are steps that will indicate our moving in this direction and
will allow reducing the number of packages to be changed.

-- 
Dmitry Belyavskiy
--
___
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: Reminder: F40 final freeze starts next week (2024-04-02)

2024-04-02 Thread Jerry James

On Tue, Apr 2, 2024 at 10:08 AM Sandro  wrote:
> We are one week down the road. I've submitted an update a week ago
> shortly after Adam's reply was sent (March 26, 21:48 UTC). Final freeze
> is now in effect and the update[1] has *not* made it to stable. It's
> still in testing.
>
> Luckily, this update can wait until after freeze. I'm glad I decided to
> ask for karma for another update submitted earlier the same day.
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ebd1e2c45

I've had this bite me in previous years.  If you submit an update on
Tuesday, then it will be pushed to testing Tuesday night.  One week
later, on Tuesday night again, it will be submitted for stable, and 24
hours later it will actually go stable.  It takes 8 days to get an
update from submission to stable, not 7, so when there are only 7 days
between Beta release and Final Freeze, you're already too late when
the Beta release happens.

I personally wish we would keep the "3 days to stable" rule all the
way up to Final Freeze.  Switching to the 7 day time period right
before that always slows me down just when I'm trying to hurry and fix
things for the final freeze.  Also:
- We don't switch from 3 to 7 days at Beta Release, but rather when
the Beta Release is announced, which is typically 4 to 5 days prior to
the Beta Release.
- We retroactively change the time to stable of all updates that have
already been submitted.  I might have an update that I think will go
stable in 1 more day, and suddenly it isn't going to go stable for 5
more days.

All of that combined means extra delays just when time is short.
-- 
Jerry James
http://www.jamezone.org/
--
___
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

Orphaned packages looking for new maintainers

2024-04-02 Thread Maxwell G

Report started at 2024-04-02 16:05:20 UTC

The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will be retired when the affected package gets retired.

Request package ownership via the *Take* button in the left column on
https://src.fedoraproject.org/rpms/

Full report available at:
https://a.gtmx.me/orphans/orphans.txt
grep it for your FAS username and follow the dependency chain.

For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan

Package  (co)maintainers   Status Change

botan orphan   1 weeks ago  
container-workflow-tool   orphan   1 weeks ago  
emacs-htmlize orphan   1 weeks ago  
kio-upnp-ms   jgrulich, orphan 3 weeks ago  
ktp-contact-runner@kde-sig, orphan, rdieter3 weeks ago  
liquidshell   orphan   5 weeks ago  
loudgain  orphan   3 weeks ago  
mrxvt orphan   3 weeks ago  
nextcloud ichavero, orphan 1 weeks ago  
perl-Git-PurePerl iarnell, orphan  6 weeks ago  
perl-Net-GitHub   jplesnik, lkundrak, orphan,  6 weeks ago  
  ppisar
perl-Spreadsheet-ParseExcel-  jplesnik, orphan, ppisar 6 weeks ago  
Simple  
perl-Spreadsheet-WriteExcel-  jplesnik, orphan, ppisar 6 weeks ago  
Simple  
perl-String-Diff  iarnell, orphan  6 weeks ago  
perl-WWW-Google-Contacts  orphan   3 weeks ago  
php-aws-sdk3  orphan   1 weeks ago  
php-bantu-ini-get-wrapper adamwill, orphan 1 weeks ago  
php-christophwurst-id3parser  orphan   1 weeks ago  
php-deepdiver-zipstreamer orphan   1 weeks ago  
php-doctrine-dbal orphan, remi 1 weeks ago  
php-fgrosse-phpasn1   orphan   1 weeks ago  
php-giggsey-localeorphan   1 weeks ago  
php-guzzlehttp-guzzle6orphan   1 weeks ago  
php-league-uri-interfaces orphan   1 weeks ago  
php-opencloud-openstack   orphan   1 weeks ago  
php-opis-closure  orphan, remi 1 weeks ago  
php-phpSmug   orphan   5 weeks ago  
php-pimpleorphan   1 weeks ago  
php-punic orphan   1 weeks ago  
php-ralouphie-getallheaders   orphan   1 weeks ago  
php-scssphp   orphan   1 weeks ago  
php-stecman-symfony-console-  orphan   1 weeks ago  
completion  
python-aiomqttorphan   4 weeks ago  
python-autoprop   orphan   4 weeks ago  
python-colorcet   orphan   4 weeks ago  
python-extractcode@python-packagers-sig, orphan3 weeks ago  
python-jose   orphan   0 weeks ago  
python-limits orphan   3 weeks ago  
python-param  orphan   4 weeks ago  
python-pyct   orphan   4 weeks ago  
python-signature-dispatch orphan   4 weeks ago  
python-vecrec orphan   4 weeks ago  
telepathy-logger-qt   @kde-sig, jgrulich, orphan   3

Re: Reminder: F40 final freeze starts next week (2024-04-02)

2024-04-02 Thread Fabio Valentini

On Tue, Apr 2, 2024 at 6:08 PM Sandro  wrote:
>
> On 26-03-2024 22:15, Adam Williamson wrote:
> > On Tue, 2024-03-26 at 21:34 +0100, Sandro wrote:
> >> On 26-03-2024 16:25, Kevin Fenzi wrote:
> >>> So, please take this time to do any last minute testing and bugfixing
> >>> and make sure any packages you expect to be in the final f40 base
> >>> repositories are pushed stable before next Tuesday (2024-04-02).
> >>
> >> I was just wondering, and someone else with me, if today's updates would
> >> still make it in time?
> >>
> >> If not, I thank you for the reminder nonetheless, but would also like to
> >> ask to have it sent in time for updates to still be able to land in the
> >> release before freeze happens.
> >>
> >> Of course, there's always the option of going around begging for
> >> (instant) karma ...
> >
> > You still have a week until next Tuesday, so...yes.
>
> We are one week down the road. I've submitted an update a week ago
> shortly after Adam's reply was sent (March 26, 21:48 UTC). Final freeze
> is now in effect and the update[1] has *not* made it to stable. It's
> still in testing.
>
> Luckily, this update can wait until after freeze. I'm glad I decided to
> ask for karma for another update submitted earlier the same day.
>
> [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ebd1e2c45

Yes, 7 days between end of beta freeze and start of final freeze is
not enough to land an update that has autotime=7days. Which is really
annoying.
Maybe next time we can make the non-freeze period last like 8-9 days?
One week (especially if that week contains the Easter holiday) is not
enough.

Fabio
--
___
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: Reminder: F40 final freeze starts next week (2024-04-02)

2024-04-02 Thread Sandro


On 26-03-2024 22:15, Adam Williamson wrote:

On Tue, 2024-03-26 at 21:34 +0100, Sandro wrote:

On 26-03-2024 16:25, Kevin Fenzi wrote:

So, please take this time to do any last minute testing and bugfixing
and make sure any packages you expect to be in the final f40 base
repositories are pushed stable before next Tuesday (2024-04-02).


I was just wondering, and someone else with me, if today's updates would
still make it in time?

If not, I thank you for the reminder nonetheless, but would also like to
ask to have it sent in time for updates to still be able to land in the
release before freeze happens.

Of course, there's always the option of going around begging for
(instant) karma ...


You still have a week until next Tuesday, so...yes.


We are one week down the road. I've submitted an update a week ago 
shortly after Adam's reply was sent (March 26, 21:48 UTC). Final freeze 
is now in effect and the update[1] has *not* made it to stable. It's 
still in testing.


Luckily, this update can wait until after freeze. I'm glad I decided to 
ask for karma for another update submitted earlier the same day.


[1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-3ebd1e2c45

-- Sandro

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

* Kilian Hanich via devel:

> Am 02.04.24 um 10:22 schrieb Florian Weimer:
>>>   - Can some wrappers be developed to make it both easier and safer?
>> GCC already provides function multi-versioning/target clones as a
>> higher-level interface.
>
>
> Also, upstreams should by default properly mark their stuffs with
> restrictive visibilities.
>
> While we are a few decades to change the defaults, that doesn't mean
> that one can't choose the better option. So, by default one should
> choose -fvisibility=hidden and mark the public API with
> __attribute__((visibility("protected"))) or, if they really want a
> function to be interpositionable (by e.g. LD_PRELOAD) as
> __attribute__((visibility("default"))).

I think protected visibility is still broken on x86-64.  For function
symbols, it's more convenient to use -fno-semantic-interposition and
rely on LTO to do the heavy lifting.  For data symbols, it may be a
better longer term investment to add explicit export lists (maybe even
with symbol versioning), and again rely on LTO to make everything else
hidden.

Thanks,
Florian
--
___
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: Fedora Linux 40 Final Freeze

On Tue, Apr 02, 2024 at 02:24:51PM +0200, Frantisek Zatloukal wrote:
> On Tue, Apr 2, 2024 at 12:39 PM Jakub Jelinek  wrote:
> 
> > sting->stable marked updates be still included in
> > stable without having to go through the exception/blocker process?
> >
> 
> I was told there would be one more stable push at the releng channel on
> matrix.

Yeah, there's a final stable push right before freezing. 

Thats been done, so check now if you still are looking to get anything
in. If so, it will need a approved freeze exception or blocker.

kevin


signature.asc
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: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

2024-04-02 Thread Gary Buhrmaster

On Tue, Apr 2, 2024 at 3:12 PM Dmitry Belyavskiy  wrote:

> Third-party engines may be a problem but as we don't break ABI, it's not a 
> problem of the moment.

The fact you are removing the headers means it is
a problem for 3rd party engines who build from
source (and everyone should at least occasionally
be building from source as part of their CI).

I consider removing the headers as breaking
the API, as the headers define the API.
The headers already mark the engine APIs
as deprecated.  Orgs with resources should
be starting their migration, although some
will defer it to the next quarter (and the
next)

I expect you have no visibility into 3rd party
engines, nor how big an issue this will be
(and can make no statistically valid claim
it will not be an issue unless you have real
numbers to share).  However, *after* RHEL10
is released with engine support removed
RH's TAMs may have a better idea (I am
WAGing most 3rd party engines will be
being used by large customers, and they
are likely to make any concerns known).

I believe this should be part of OpenSSL 4.0.
It will be a clear change.  There is no
compelling reason for this to happen
today via the headers.  Instead this should
be a marketing campaign by OpenSSL
to remind everyone that engines are
going away with OpenSSL 4.0 with every
new set of release notes (first item,
in double bold), and that orgs need to
start their migration.  And then do it again.
 And then do it again.  And when OpenSSL
4.0 is released, you can remind everyone
you warned them.
--
___
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

2024-04-02 Thread Simo Sorce

On Sat, 2024-03-30 at 15:23 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Sat, Mar 30, 2024 at 07:25:50AM -0500, Chris Adams wrote:
> > Once upon a time, Michael Catanzaro  said:
> > > I agree that running autoreconf on our packages makes sense to start
> > > doing. Still, to avoid this backdoored m4 file, we would have needed
> > > to stop using release tarballs altogether and switch to using git
> > > tags directly instead. That would at least force the malicious
> > > attacker to commit their code to version control, making it slightly
> > > harder to hide the attack.
> > 
> > Using a signed tarball is ideally better than a git tag (it's an extra
> > level of author attestation)... but where both are available, it'd be
> > nice to have a way to denote in the spec file that there are two URLs
> > for the source.  In this case, if both URLs were listed and something
> > could be run to automatically fetch and compare them, the attack code
> > would have been flagged.
> 
> Tarball production should be reproducible. Then the maintainer can
> both make a signature locally and make it public, and users can download
> the auto-generated tarball.
> 
> In fact, github tarball generation is stable. A few years ago they tried
> to improve the compression method (i.e. .tar would be still identical,
> but .tar.gz would be different), and after a huge outcry this was reverted.
> They still haven't officially said that it's stable, but let's hope that
> it never changes, at least not without a suitable advance warning.

I do not know if this changed in the last couple of years, but tarballs
in github are not stable (or weren't up to a couple years ago), they
are cached for a period of time, so they may look stable in busy
projects where you have regular downloads that keep the cache alive,
but they are *regenerated* from the tag for seldom downloaded tarballs.
And when that happens then hashes change.

Simo.

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc







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

2024-04-02 Thread Richard W.M. Jones

On Tue, Apr 02, 2024 at 12:45:18AM -0700, Gordon Messmer wrote:
> On 2024-04-01 23:59, Gordon Messmer wrote:
> >Now gdb can print the GOT with the paths providing the memory
> >section containing a function.  For example, on a Debian 12 system
> >with liblzma 5.6:
> 
> 
> Purely as trivia, and as I haven't seen it discussed elsewhere, the
> malware steals a different set of symbols on Fedora, where
> RSA_public_decrypt doesn't seem to appear in the GOT at all.  On
> Fedora 40:
> 
> gef➤  got RSA
> 
> GOT protection: Full RelRO | GOT functions: 503
> 
> [0x556ac0b94ff8] RSA_set0_key@OPENSSL_3.0.0  →  0x7f4e95dafce0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b951c0] RSA_bits@OPENSSL_3.0.0  →  0x7f4e95daf0a0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b951e0] EVP_PKEY_set1_RSA@OPENSSL_3.0.0  → 0x7f4e960e23b0 :
> /usr/lib64/liblzma.so.5.6.1
> [0x556ac0b95310] RSA_set0_crt_params@OPENSSL_3.0.0  → 0x7f4e95dafea0
> : /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b953c8] RSA_size@OPENSSL_3.0.0  →  0x7f4e95daf0b0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95518] RSA_new@OPENSSL_3.0.0  →  0x7f4e95db3330 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95778] RSA_get0_crt_params@OPENSSL_3.0.0  → 0x7f4e95dae490
> : /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95870] RSA_free@OPENSSL_3.0.0  →  0x7f4e95db2f00 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95b90] RSA_get0_key@OPENSSL_3.0.0  →  0x7f4e960e1ac0 :
> /usr/lib64/liblzma.so.5.6.1
> [0x556ac0b95c00] RSA_get0_factors@OPENSSL_3.0.0  →  0x7f4e95dae470 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95c88] EVP_PKEY_get1_RSA@OPENSSL_3.0.0  → 0x7f4e95d59710 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95da0] RSA_get_ex_data@OPENSSL_3.0.0  →  0x7f4e95db3440 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95e50] RSA_set0_factors@OPENSSL_3.0.0  →  0x7f4e95dafdc0 :
> /usr/lib64/libcrypto.so.3.2.1
> [0x556ac0b95f00] RSA_blinding_on@OPENSSL_3.0.0  →  0x7f4e95db17f0 :
> /usr/lib64/libcrypto.so.3.2.1

Since no one else replied yet, this is a nice bit of analysis.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
--
___
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

2024-04-02 Thread Richard W.M. Jones

On Tue, Apr 02, 2024 at 05:09:18PM +0200, Kilian Hanich via devel wrote:
> Am 02.04.24 um 10:22 schrieb Florian Weimer:
> >>  - Can some wrappers be developed to make it both easier and safer?
> >GCC already provides function multi-versioning/target clones as a
> >higher-level interface.
> 
> 
> Also, upstreams should by default properly mark their stuffs with
> restrictive visibilities.
> 
> While we are a few decades to change the defaults, that doesn't mean
> that one can't choose the better option. So, by default one should
> choose -fvisibility=hidden and mark the public API with
> __attribute__((visibility("protected"))) or, if they really want a
> function to be interpositionable (by e.g. LD_PRELOAD) as
> __attribute__((visibility("default"))).

ISTR this also makes the library faster (faster loading I think?)

Anyway we've done it for all the virt libraries for years.

Rich.

> As a side effect, if you ever want your library be usable on Windows,
> you need to do that anyway since hidden is the default there and your
> public API must be marked explicitly. (Also, Windows doesn't support
> interposition and also doesn't support cyclic library dependencies
> without complicated hacks. So yeah, Windows kinda has the better
> defaults here.)
> 
> Some newer languages do that anyway already, but we obviously can't just
> change it for C and C++ projects.
> 
> But depending on the architecture this may not necessarily be possible.
> So yeah, only upstream can do that, not us.
> 
> 
> Regards
> 
> Kilian Hanich
> --
> ___
> 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

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
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: Golang bundled() Provides generator

2024-04-02 Thread Dan Čermák

Hi Maxwell & Go SIG,

we have recently started working on introducing a bundled() provides
generator for golang in openSUSE and found a very simple solution using
the output of `go version -m /path/to/binary` [1]

The solution is of course only that simple, because we build more or
less all go binaries with vendored dependencies and hence we do not need
to distinguish between those build with vendored and those build
without.

As I would like to align the Fedora and openSUSE go packaging closer
together and hence, if possible, find a solution to use this generator
for both Fedora and openSUSE. I think it is a bit simpler and does not
require to ship the modules.txt in the final rpm. However, I see that
both are rather weak reasons.

Do you see a way how we can find a common solution? E.g. by having a
macro %go_enable_bundled_provides that would set an environment variable
and enable the bundled generator?


Cheers,

Dan

Footnotes:
[1]  https://github.com/dcermak/golang-packaging/blob/master/golang.prov
--
___
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: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

2024-04-02 Thread Dmitry Belyavskiy

Dear Luca

On Tue, Apr 2, 2024 at 4:32 PM Luca Boccassi  wrote:

> > Hi Zbigniew!
> >
> > On Tue, Apr 2, 2024 at 1:15 PM Zbigniew Jędrzejewski-Szmek <
> > zbyszek(a)in.waw.pl wrote:
> >
> >
> > Thanks. In the period between the proposal was written and published the
> > TPM2 provider has landed in Fedora.
> > PKCS#11 provider is already here for a while.
>
> The fact that such packages are physically present is not enough - they
> need to implement all the needed features, and they need to be mature
> enough to just work out of the box. Neither of these are true today, and
> providers just do not work for very simple use cases like signing a UKI
> with a yubikey. At the very least a couple more years of development and
> testing is needed before they are anywhere near ready to drop support for
> engines, that actually do work out of the box. Not to mention third party
> engines that are specific to internal/private build systems - if any such
> system runs Fedora as the build host, they'd have to migrate to
> Debian/Ubuntu to keep working.
>

The TPM2 package is suitable for all required operations, AFAIK.
I'm also sure about the PKCS11 provider which I follow close enough.

Please raise detailed issues if you have something particular.
I remember that you mentioned a particular issue about PKCS#11, could you
please try the current version?
My colleagues working on PKCS#11 are not aware of any Yubikey issues, BTW.

Third-party engines may be a problem but as we don't break ABI, it's not a
problem of the moment.

-- 
Dmitry Belyavskiy
--
___
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

2024-04-02 Thread Kilian Hanich via devel


Am 02.04.24 um 10:22 schrieb Florian Weimer:

  - Can some wrappers be developed to make it both easier and safer?

GCC already provides function multi-versioning/target clones as a
higher-level interface.



Also, upstreams should by default properly mark their stuffs with
restrictive visibilities.

While we are a few decades to change the defaults, that doesn't mean
that one can't choose the better option. So, by default one should
choose -fvisibility=hidden and mark the public API with
__attribute__((visibility("protected"))) or, if they really want a
function to be interpositionable (by e.g. LD_PRELOAD) as
__attribute__((visibility("default"))).

As a side effect, if you ever want your library be usable on Windows,
you need to do that anyway since hidden is the default there and your
public API must be marked explicitly. (Also, Windows doesn't support
interposition and also doesn't support cyclic library dependencies
without complicated hacks. So yeah, Windows kinda has the better
defaults here.)

Some newer languages do that anyway already, but we obviously can't just
change it for C and C++ projects.

But depending on the architecture this may not necessarily be possible.
So yeah, only upstream can do that, not us.


Regards

Kilian Hanich
--
___
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: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

2024-04-02 Thread Luca Boccassi

> Hi Zbigniew!
> 
> On Tue, Apr 2, 2024 at 1:15 PM Zbigniew Jędrzejewski-Szmek <
> zbyszek(a)in.waw.pl wrote:
> 
> 
> Thanks. In the period between the proposal was written and published the
> TPM2 provider has landed in Fedora.
> PKCS#11 provider is already here for a while.

The fact that such packages are physically present is not enough - they need to 
implement all the needed features, and they need to be mature enough to just 
work out of the box. Neither of these are true today, and providers just do not 
work for very simple use cases like signing a UKI with a yubikey. At the very 
least a couple more years of development and testing is needed before they are 
anywhere near ready to drop support for engines, that actually do work out of 
the box. Not to mention third party engines that are specific to 
internal/private build systems - if any such system runs Fedora as the build 
host, they'd have to migrate to Debian/Ubuntu to keep working.
--
___
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

[Bug 2266094] perl-Compress-Raw-Zlib-2.209 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Compress-Raw-Zlib-2.20 |perl-Compress-Raw-Zlib-2.20
   |9-1.fc41|9-1.fc41
   ||perl-Compress-Raw-Zlib-2.20
   ||9-1.fc40



--- Comment #5 from Fedora Update System  ---
FEDORA-2024-4007a7bed3 (perl-Compress-Raw-Zlib-2.209-1.fc40) has been pushed to
the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2266094

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202266094%23c5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2265610] perl-Log-ger-0.042 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Log-ger-0.042-1.fc41   |perl-Log-ger-0.042-1.fc41
   ||perl-Log-ger-0.042-1.fc40



--- Comment #5 from Fedora Update System  ---
FEDORA-2024-8e17c24798 (perl-Log-ger-0.042-1.fc40) has been pushed to the
Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2265610

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202265610%23c5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2269439] perl-HTML-Parser-3.82 is available

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-HTML-Parser-3.82-1.fc4 |perl-HTML-Parser-3.82-1.fc4
   |1   |1
   ||perl-HTML-Parser-3.82-1.fc4
   ||0



--- Comment #7 from Fedora Update System  ---
FEDORA-2024-1663894056 (perl-HTML-Parser-3.82-1.fc40) has been pushed to the
Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2269439

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202269439%23c7
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

2024-04-02 Thread Dmitry Belyavskiy

Hi Zbigniew!

On Tue, Apr 2, 2024 at 1:15 PM Zbigniew Jędrzejewski-Szmek <
zbys...@in.waw.pl> wrote:

> On Tue, Apr 02, 2024 at 10:45:32AM +0100, Aoife Moloney wrote:
> > == Summary ==
> > We disable building the packages using ENGINE API in OpenSSL without
> > breaking ABI.
>
> "Without breaking ABI" is a improvement.
> Everything else — not so much.
>
> > == Detailed Description ==
> > We are going to deprecate OpenSSL engine support. Engines are not FIPS
> > compatible and corresponding API is deprecated since OpenSSL 3.0. The
> > engine functionality we are aware of (PKCS#11, TPM) is either covered
> > by providers or will be covered soon.
>
> This doesn't really answer the problems that were raised in the previous
> round of discussion. Even if the plan is that some functionality will
> be provided "soon", dropping engine support _right now_ will cause problems
> for developers and for users: first the providers need to become available
> and have the complete feature set, then the upstreams have add the relevant
> provider code and document things so that users know how to adapt,
> and then we need to integrate all of that downstream in packaging.
>
> If we start be ripping out the engine functionality, we'll have a
> window, of unpredictable length, where the functionality will not be
> available. This is bad for users, but also breaks the promise that
> Fedora is the best environment for upstream development.
>

Thanks. In the period between the proposal was written and published the
TPM2 provider has landed in Fedora.
PKCS#11 provider is already here for a while.

Should I update the Wiki page to adjust this point?

> We don't plan to remove the API from libcrypto.so. We are going to
> > prevent creating the new packages dependent on OpenSSL ENGINE API and
> > remove ENGINE dependencies from the existing packages.
>
> IIUC, this is implemented by dropping the header files. This is
> not acceptable: it would break package rebuilds.
>

It's our goal - to eliminate the engine dependency. While a package can be
built, it gets lower priority.

> == Benefit to Fedora ==
> > We get rid of deprecated functionality and enforce using up-to-date
> > API. Engine support is deprecated in OpenSSL upstream, and after
> > provider migration caused some deficiencies with engine support. No
> > new features will be added to engine. So we reduce maintenance burden
> > and potentially attack surface.
> >
> > It follows approach planned for CentOS 10.
>
> Such things are always a tradeoff. The benefit of removing the deprecated
> code obviously reduced the maintanance burder a bit. But is is really
> that much? OTOH, it disables features that are being used or developed
> in a bunch of important projects. It seems very premature to take this
> step for F41, i.e. sometime within the next two—three months. It seems
> that the ecosystem isn't ready.
>

I want to encourage the ecosystem to move to a viable target.

>
> The tradeoff for CentOS 10 is different: the first release is still
> a while away and most people will not jump onto the 10.0 release anyway.
> By the time CentOS is used in anger, the ecosystem might be ready.
> This is one of the cases where using Fedora as a pre-release for CentOS
> as a pre-release for RHEL is detrimental to Fedora.
>

I agree.

> == How To Test ==
> > OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40.
> > Applications relying on the ENGINE API can't be built but still work.
>
> That's incompatible with package rebuilds…
>
> An acceptable approach would be to split out the headers to a separate
> -devel file, e.g. openssl-engine-devel, mark it as Provides: deprecated().
> Existing packages which need the engine headers can adjust to use the
> new header and new packages are prevented by the Packaging Guidelines
> from adding a dependency on deprecated packages.
>

Thanks! I like this idea and can update the Wiki page accordingly.

-- 
Dmitry Belyavskiy
--
___
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

2024-04-02 Thread Vít Ondruch



Dne 30. 03. 24 v 18:26 Artem S. Tashkinov via devel napsal(a):

Hi,

It was sheer luck that the exploit was discovered and major distros haven't yet 
included it in their stable releases. It's quite possible and plausible it 
could have reached RHEL, Debian, Ubuntu, SLES and other distros and it's almost 
reached Fedora 40.

I don't know how to talk to RedHat/IBM/FSF/Ubuntu and all the big players 
behind Open Source/Linux but I want to raise a very important issue.

There's near zero accountability for the tens of thousands of packages included in Linux 
distros, often by maintainers who have no resources, qualifications or even know any 
programming languages to spot the "bad" code and raise an alarm. Upstream 
packages are pushed into Linux distros without considerationand that's it.

That's all completely unacceptable on multiple levels. Security is a joke as a result of 
this considering the infamous "Jia Tan" who was almost the sole maintainer of 
XZ for over two years.

I propose this issue to be tackled in a centralized way by the collaboration of 
major distros.



If I was JT, I would applaud this proposal. This would give me an 
opportunity to infiltrate such powerful body and either


1) close my eyes above some of the reviewed content from the right 
parties or


2) have some nice proposal such as "do you think your code is correct 
and won't you include rather this specially crafted piece of  code?"



But since I am not JT, I prefer the current decentralized approach.


Vít




There must be a website or a central authority which includes known to be 
good/safe/verified/vetted open source packages along with e.g. 
SHA256/384/512/whatever hashes of the source tarballs. In addition, the source 
tarballs (not their compressed versions because people may use different 
compressors and compression settings) and their hashes must be digitally signed 
or have the appropriate PGP signatures from the trusted parties.

Some parties must be assigned trust to be able to push new packages to this 
repository. Each push must be verified by at least two independent parties, 
let's say RedHat and Ubuntu or Ubuntu and Arch, it doesn't matter. The 
representatives of these parties must be people whose whereabouts are known to 
confirm who they physically are. No nicknames allowed.

This website must also have/allow a revocation mechanism for situations like 
this.

Now Fedora/Arch/Debian/Ubuntu/whatever distros can build packages knowing they 
are safe to use.

If that's the wrong place to come up with this proposal, please forward it to 
the people who are responsible for making such decisions. I'm not willing to 
dig through the dirt to understand how the Fedora project works, who is 
responsible for what, and what are the appropriate communication channels. If 
you care, you'll simply forward my message. Thanks a lot.

Best regards,
Artem
--
___
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


OpenPGP_signature.asc
Description: OpenPGP digital 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

2024-04-02 Thread Vít Ondruch

Dne 30. 03. 24 v 22:14 Zbigniew Jędrzejewski-Szmek napsal(a):

On Sat, Mar 30, 2024 at 08:00:29PM +0100, Kevin Kofler via devel wrote:

Zbigniew Jędrzejewski-Szmek wrote:

I think there's some useful points here, but this would need to be
qualified and/or made more flexible to be applied.

For example, systemd repo has fuzzer case files, which are a mix of
text, mojibake, and actual binary protocol samples. For example, dhcp
input packets, dns packets. There are also other ~binary test files,
for example corrupted journal files.

The tests are defined via meson.build, so those files are "referred to
in the build tools", and would not be allowed by the above definition.
But if we dropped those, we'd lose very valuable testing of the codebase.

On the other hand, "test files" are exactly how the payload of this backdoor
was disguised! So a policy that deletes all binary test files or even all
test files altogether would have prevented this backdoor.

Well, if we made a rule that "binary" files are not allowed

I think that we should really not talk about binary files and talk e.g.
about pre-generated files instead. This chapter in guidelines is already
trying to cover this:

https://docs.fedoraproject.org/en-US/packaging-guidelines/what-can-be-packaged/#pregenerated-code

But maybe we should rewrite the "No inclusion of pre-built binaries or
libraries" chapter above to be more generic.

Vít

, the
attacker would e.g. commit some minified bash that generates whatever output
is needed. The real problem was the complex and unreadable build system
that made it easy to embed _multiple_ obfuscated components for the attack.

To trust code, it needs to be reviewed. And if the code is reviewed,
and the build system is sane, it's usually fairly easy to say "oh,
this is a sample and the only way it's used is as input to a fuzzer
binary", or "this sample is used as input to a unit test", etc.

A policy against binary files would hinder this particular implementation
of the attack, but the attacker had full control of the repo, so they
would be able to arrange the attack around such a policy without too
much trouble.

Zbyszek
--
___
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

OpenPGP_signature.asc
Description: OpenPGP digital 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: xz backdoor

2024-04-02 Thread Stephen Smoogen

On Tue, 2 Apr 2024 at 08:18, Lennart Poettering 
wrote:

> On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote:
>
>
> > Could be even smaller library libsystemd-notify linked from libsystemd,
> > which would allow end applications to explicitly declare they need more
> > limited set of functions?
>
> Why link? I'd really just suggest people to implement the trivial
> client on their own. It's a trivial protocol for a reason: so that
> people can implement it natively in their language and framwork
> without bothering with our upstream libsystemd.
>
>
I think because enough people have learned that anything which is listed as
a 'trivial protocol' tends to get messed up if you don't really
understand it. Many developers have also learned that if you mess up a
'trivial protocol' you tend to get blamed for being an idiot or worse so it
is better to just find something which already implements it, is tested and
known to work and move on with your day. I think the two combined with some
other social reasons are why various modern languages (go, python, java,
rust, etc) have grown giant ecosystems where packages focus on implementing
a trivial thing and you are to include just that versus a library of other
things. [Of course you then end up with 30 ways to implement the same
trivial thing which pull in various other trivial things...]

I am not saying this is good behaviour or what should be done, but it seems
expected these days.



> use libsystemd if you link against it anways and hack in C, or if you
> really don't are about the extra dep for a single function, but
> otherwise, why would you use the lib?
>
> It *literally* is just sending a text string "READY=1" in an AF_UNIX
> datagram to a socket whose path is provided to you in the
> $NOTIFY_SOCKET env var. Anyone with a moderate understanding of UNIX
> APIs should be able to hack that up in a a few lines of code. It's a
> protocol I can summarize and explain in *one* frickin' sentence.
>
> sshd upstream understood this btw:
>
> https://bugzilla.mindrot.org/show_bug.cgi?id=2641
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> --
> ___
> 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
>


-- 
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
--
___
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

Fedora 40 compose report: 20240402.n.0 changes

2024-04-02 Thread Fedora Branched Report

OLD: Fedora-40-20240401.n.0
NEW: Fedora-40-20240402.n.0

= SUMMARY =
Added images:1
Dropped images:  3
Added packages:  1
Dropped packages:3
Upgraded packages:   343
Downgraded packages: 0

Size of added packages:  41.93 MiB
Size of dropped packages:16.87 MiB
Size of upgraded packages:   3.33 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   -45.54 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: LXQt live aarch64
Path: Spins/aarch64/iso/Fedora-LXQt-Live-aarch64-40-20240402.n.0.iso

= DROPPED IMAGES =
Image: i3 live aarch64
Path: Spins/aarch64/iso/Fedora-i3-Live-aarch64-40-20240401.n.0.iso
Image: Workstation live aarch64
Path: 
Workstation/aarch64/iso/Fedora-Workstation-Live-aarch64-40-20240401.n.0.iso
Image: Kinoite ociarchive ppc64le
Path: Kinoite/ppc64le/images/Fedora-Kinoite-40.20240401.n.0.ociarchive

= ADDED PACKAGES =
Package: golang-github-edoardottt-lit-bb-hack-tools-1.3.5-1.fc40
Summary: Little Bug Bounty & Hacking Tools
RPMs:golang-github-edoardottt-lit-bb-hack-tools
Size:41.93 MiB


= DROPPED PACKAGES =
Package: openssl1.1-1:1.1.1q-7.fc40
Summary: Compatibility version of the OpenSSL library
RPMs:openssl1.1 openssl1.1-devel
Size:16.80 MiB

Package: rust-versionize-0.2.0-2.fc40
Summary: Version tolerant serialization/deserialization framework
RPMs:rust-versionize+default-devel rust-versionize-devel
Size:39.70 KiB

Package: rust-versionize_derive-0.1.6-2.fc40
Summary: Implements the Versionize derive proc macro
RPMs:rust-versionize_derive+default-devel rust-versionize_derive-devel
Size:31.46 KiB


= UPGRADED PACKAGES =
Package:  airinv-1.00.9-1.fc40
Old package:  airinv-1.00.8-8.fc40
Summary:  C++ Simulated Airline Inventory Management System library
RPMs: airinv airinv-devel airinv-doc
Size: 3.73 MiB
Size change:  -14.82 KiB
Changelog:
  * Sat Mar 23 2024 Denis Arnaud  - 1.00.9-1
  - Upstream upgrade


Package:  airrac-1.00.8-1.fc40
Old package:  airrac-1.00.7-9.fc40
Summary:  C++ Simulated Revenue Accounting (RAC) System Library
RPMs: airrac airrac-devel airrac-doc
Size: 1.24 MiB
Size change:  -10.48 KiB
Changelog:
  * Sat Mar 23 2024 Denis Arnaud  - 1.00.8-1
  - Upstream upgrade


Package:  airtsp-1.01.11-1.fc40
Old package:  airtsp-1.01.10-7.fc40
Summary:  C++ Simulated Airline Travel Solution Provider Library
RPMs: airtsp airtsp-devel airtsp-doc
Size: 2.42 MiB
Size change:  -18.35 KiB
Changelog:
  * Sat Mar 23 2024 Denis Arnaud  - 1.01.11-1
  - Upstream upgrade


Package:  akonadi-calendar-24.02.1-1.fc40
Old package:  akonadi-calendar-24.02.0-1.fc40
Summary:  The Akonadi Calendar Library
RPMs: akonadi-calendar akonadi-calendar-devel akonadi-calendar-doc
Size: 2.04 MiB
Size change:  -349.05 KiB
Changelog:
  * Sun Mar 10 2024 Marie Loise Nolden  - 24.02.0-2
  - add missing BuildArch: noarch to -doc package

  * Fri Mar 29 2024 Marc Deop i Argem??  - 24.02.1-1
  - 24.02.1


Package:  akonadi-calendar-tools-24.02.1-1.fc40
Old package:  akonadi-calendar-tools-24.02.0-1.fc40
Summary:  Akonadi Calendar Tools
RPMs: akonadi-calendar-tools
Size: 969.93 KiB
Size change:  4.21 KiB
Changelog:
  * Fri Mar 29 2024 Marc Deop i Argem??  - 24.02.1-1
  - 24.02.1


Package:  akonadi-contacts-24.02.1-1.fc40
Old package:  akonadi-contacts-24.02.0-1.fc40
Summary:  The Akonadi Contacts Library
RPMs: akonadi-contacts akonadi-contacts-devel akonadi-contacts-doc
Size: 4.06 MiB
Size change:  -1.96 MiB
Changelog:
  * Sat Mar 09 2024 Marie Loise Nolden  - 24.02.0-2
  - add missing BuildArch: noarch to -doc package

  * Fri Mar 29 2024 Marc Deop i Argem??  - 24.02.1-1
  - 24.02.1


Package:  akonadi-import-wizard-24.02.1-1.fc40
Old package:  akonadi-import-wizard-24.02.0-1.fc40
Summary:  Akonadi Import Wizard
RPMs: akonadi-import-wizard akonadi-import-wizard-devel
Size: 1.63 MiB
Size change:  342 B
Changelog:
  * Fri Mar 29 2024 Marc Deop i Argem??  - 24.02.1-1
  - 24.02.1


Package:  akonadi-mime-24.02.1-1.fc40
Old package:  akonadi-mime-24.02.0-1.fc40
Summary:  The Akonadi Mime Library
RPMs: akonadi-mime akonadi-mime-devel akonadi-mime-doc
Size: 1.96 MiB
Size change:  -983.35 KiB
Changelog:
  * Sat Mar 09 2024 Marie Loise Nolden  - 24.02.0-2
  - add missing BuildArch: noarch to -doc package

  * Fri Mar 29 2024 Marc Deop i Argem??  - 24.02.1-1
  - 24.02.1


Package:  akonadi-notes-24.02.1-1.fc40
Old package:  akonadi-notes-24.02.0-1.fc40
Summary:  The Akonadi Notes Library
RPMs: akonadi-notes akonadi-notes-devel akonadi-notes-doc
Size: 546.73 KiB
Size change:  -341.05 KiB
Changelog:
  * Sat Mar 09 2024 Marie Loise Nolden  - 24.02.0-2
  - add missing BuildArch: noarch to -doc package

  * Fri Mar 29 2024 Marc Deop i Argem??  - 24.02.1-1
  - 24.02.1


Pac

Re: Fedora Linux 40 Final Freeze

2024-04-02 Thread Frantisek Zatloukal

On Tue, Apr 2, 2024 at 12:39 PM Jakub Jelinek  wrote:

> sting->stable marked updates be still included in
> stable without having to go through the exception/blocker process?
>

I was told there would be one more stable push at the releng channel on
matrix.


-- 

Best regards / S pozdravem,

František Zatloukal
Senior Quality Engineer
Red Hat
--
___
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

[Bug 2272636] perl-SDL-2.548-22.fc41 FTBFS with SDL2-2.30.1: t/core_events.t fails: Can't use an undefined value as a subroutine reference during global destruction

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



--- Comment #4 from Fedora Update System  ---
FEDORA-2024-176c95f1c4 (perl-SDL-2.548-23.fc40) has been submitted as an update
to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-176c95f1c4


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272636

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272636%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

2024-04-02 Thread Lennart Poettering

On Di, 02.04.24 14:04, Petr Menšík (pemen...@redhat.com) wrote:

> I am not convinced dlopen will it make secure in the end. I am not sure this
> is a good solution. dlopen makes those dependencies non-obvious from
> packaging side and non-visible from ldd or similar checking programs.
>
> I think it should be considered to offer more than one dynamic
> library.

It was considered. To the point that a decade ago, libsystemd
originally was split up. But it was awful to maintain.

But let's not repeat this discussion here. Read up here:
https://github.com/systemd/systemd/issues/32028

> For example most services I maintain links to libsystemd just
> because it wants sd_notify calls in their services. Without any
> proof I would expect quite many services would have similar
> problem. Could be perhaps libsystemd broken into few more dynamic
> linked libraries? I somehow doubt any kind of compression is needed
> for sd_notify calls.
>
> Could be even smaller library libsystemd-notify linked from libsystemd,
> which would allow end applications to explicitly declare they need more
> limited set of functions?

Why link? I'd really just suggest people to implement the trivial
client on their own. It's a trivial protocol for a reason: so that
people can implement it natively in their language and framwork
without bothering with our upstream libsystemd.

use libsystemd if you link against it anways and hack in C, or if you
really don't are about the extra dep for a single function, but
otherwise, why would you use the lib?

It *literally* is just sending a text string "READY=1" in an AF_UNIX
datagram to a socket whose path is provided to you in the
$NOTIFY_SOCKET env var. Anyone with a moderate understanding of UNIX
APIs should be able to hack that up in a a few lines of code. It's a
protocol I can summarize and explain in *one* frickin' sentence.

sshd upstream understood this btw:

https://bugzilla.mindrot.org/show_bug.cgi?id=2641

Lennart

--
Lennart Poettering, Berlin
--
___
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

[Bug 2272636] perl-SDL-2.548-22.fc41 FTBFS with SDL2-2.30.1: t/core_events.t fails: Can't use an undefined value as a subroutine reference during global destruction

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

Petr Pisar  changed:

   What|Removed |Added

   Fixed In Version||perl-SDL-2.548-23.fc41
Version|rawhide |40
 Status|ASSIGNED|MODIFIED



--- Comment #3 from Petr Pisar  ---
The new SDL2 is coming to F40 too.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272636

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272636%23c3
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: xz backdoor

2024-04-02 Thread Petr Menšík

I am not convinced dlopen will it make secure in the end. I am not sure 
this is a good solution. dlopen makes those dependencies non-obvious 
from packaging side and non-visible from ldd or similar checking programs.


I think it should be considered to offer more than one dynamic library. 
For example most services I maintain links to libsystemd just because it 
wants sd_notify calls in their services. Without any proof I would 
expect quite many services would have similar problem. Could be perhaps 
libsystemd broken into few more dynamic linked libraries? I somehow 
doubt any kind of compression is needed for sd_notify calls.


Could be even smaller library libsystemd-notify linked from libsystemd, 
which would allow end applications to explicitly declare they need more 
limited set of functions?


Is there now relatively simple way to analyze packages depending on 
libsystemd, how rich functionality they need to use? I somehow doubt 
many packages need explicit work with journal. If they do, okay, use 
more heavy-weight library. But quite alot of programs needs just 
sd_notify* and sd_listen* calls, maybe with addition to sd_booted.


The best example is sshd itself, which plays important role in this 
story. For a very good reason.


$ objdump -T /usr/sbin/sshd | grep sd_
  DF *UND*  (LIBSYSTEMD_209) sd_notify

Less code linked into libraries means less code needs to be analysed for 
malware or security scans. It also allows an user to explicitly declare 
just limited functions should be available.


I have made crude script getting calls used on my own system. While 
there is larger group with also journal involved, I think number of 
packages using just sd_notify, sd_listen or similar is not unimportant.


$ dnf repoquery --whatdepends systemd-libs --alldeps | sort -u | while 
read PKG; do rpm -q "$PKG" >/dev/null && echo "$PKG"; done | tee installed
$ cat installed | while read PKG; do rpm -ql "$PKG" | grep -E 
'^(/usr/s?bin/|/usr/lib64/|/usr/libexec)' | while read BIN; do objdump 
-T "$BIN" 2>/dev/null | grep -E ' (sd|udev)_' | sed -e 
's/[0-9a-f]\+\s*DF\s*\(\*UND\*\|.text\)\s*[0-9a-f]\+\s*//' -e "s|^|$PKG 
${BIN}: |" ; done; done | tee libsystemd-calls.txt


Attached the results in libsystemd-calls.txt attachment.

I would prefer ability to explicitly declare I want just limited 
functionality for cooperating with systemd, without any obscure dlopen 
calls. They are even more suspicious in low-level library and I don't 
think they should be used to solve resource limitations. They make it 
more difficult to discover actually used dependencies by static analysis 
tools. udev has already own library, perhaps notify and bus should be 
able to use with a more lightweight library too?


Regards,
Petr

(edit: attached compressed list.)

On 30. 03. 24 19:43, Zbigniew Jędrzejewski-Szmek wrote:
libsystemd is linked to compression libraries primarly because those 
compressors

are options for journald files, and we generally want to mainain the property
that all journal files from the past, as well as journal files from other
systems, can be read by later journal code.

(bzip2 is an exception here. It is only used by systemd-importd and related
tools, so libsystemd was never linked to it, IIRC.)

In recent systemd versions, dlopen is used for various compression libraries and
other libraries, so they'll be opportunistically loaded if needed, effectively
making those dependencies optional at runtime.

Conversions to use dlopen require a bit of boilerplate code and make the code
less readable, so we only would to them if there was a reason. Usually, this
reason was size and/or the dependency tree. Compression libraries are very small
and have no dependencies, so it wasn't considered important to use dlopen for
them. But now that there's a new motivation, as mentioned elsewhere in the
thread, we'll load pretty much all dependencies of libsystemd via dlopen.

Zbyszek


Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB


libsystemd-calls.txt.gz
Description: application/gzip
--
___
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

* Lennart Poettering:

> On Sa, 30.03.24 18:56, Fedora Development ML (devel@lists.fedoraproject.org) 
> wrote:
>
>> > In systemd git main, libsystemd is only linked to libc, libcap,
>> > and libgcrypt + libgpg-error. A pull request to convert that that last
>> > pair to dlopen is under review.
>>
>> That helps somewhat (it would have prevented this backdoor from working),
>> but it also makes things even less transparent: How do we know whether some
>> random sd_foobarify() function or some random foobard linked against
>> libsystemd will (always or ever (and when?)) end up dlopening liblzma or
>> not?
>>
>> Distribution packagers tend to dislike dlopen due to the hidden dependencies
>> it introduces.
>
> Well, this is certainly a valid point, but the solution is not to make
> all deps hard ones. Instead, in order to just make these deps visible
> I see multiple better alternatives:
>
> 1. teach Linux/ELF something inspired by MacOS's weak deps. i.e. allow
>ELF programs declare that some symbols shall be backed by some lib,
>but make it a weak dep that is only resolved on demand, and
>gracefully is set to NULL if the library cannot be found. If we had
>that, we'd stop using dlopen() for systemd's deps, since all we do
>is basically reimplement this concept manually.

How exactly is this implemented?  Is the object loaded on the first
function call?  I'd be worried that this made initialization even more
complicated than it is today.

Loading the object unconditionally (prior to the function call) doesn't
make a difference for objects which are always installed on the system.
They would always be loaded.

Thanks,
Florian
--
___
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

[Bug 2272636] perl-SDL-2.548-22.fc41 FTBFS with SDL2-2.30.1: t/core_events.t fails: Can't use an undefined value as a subroutine reference during global destruction

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

Petr Pisar  changed:

   What|Removed |Added

   Assignee|hdego...@redhat.com |ppi...@redhat.com
 Status|NEW |ASSIGNED




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272636
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2272636] perl-SDL-2.548-22.fc41 FTBFS with SDL2-2.30.1: t/core_events.t fails: Can't use an undefined value as a subroutine reference during global destruction

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

Petr Pisar  changed:

   What|Removed |Added

Link ID||Github
   ||PerlGameDev/SDL/pull/308




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272636
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

2024-04-02 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Apr 02, 2024 at 10:45:32AM +0100, Aoife Moloney wrote:
> == Summary ==
> We disable building the packages using ENGINE API in OpenSSL without
> breaking ABI.

"Without breaking ABI" is a improvement.
Everything else — not so much.

> == Detailed Description ==
> We are going to deprecate OpenSSL engine support. Engines are not FIPS
> compatible and corresponding API is deprecated since OpenSSL 3.0. The
> engine functionality we are aware of (PKCS#11, TPM) is either covered
> by providers or will be covered soon.

This doesn't really answer the problems that were raised in the previous
round of discussion. Even if the plan is that some functionality will
be provided "soon", dropping engine support _right now_ will cause problems
for developers and for users: first the providers need to become available
and have the complete feature set, then the upstreams have add the relevant
provider code and document things so that users know how to adapt,
and then we need to integrate all of that downstream in packaging.

If we start be ripping out the engine functionality, we'll have a
window, of unpredictable length, where the functionality will not be
available. This is bad for users, but also breaks the promise that
Fedora is the best environment for upstream development.

> We don't plan to remove the API from libcrypto.so. We are going to
> prevent creating the new packages dependent on OpenSSL ENGINE API and
> remove ENGINE dependencies from the existing packages.

IIUC, this is implemented by dropping the header files. This is
not acceptable: it would break package rebuilds.

> == Benefit to Fedora ==
> We get rid of deprecated functionality and enforce using up-to-date
> API. Engine support is deprecated in OpenSSL upstream, and after
> provider migration caused some deficiencies with engine support. No
> new features will be added to engine. So we reduce maintenance burden
> and potentially attack surface.
> 
> It follows approach planned for CentOS 10.

Such things are always a tradeoff. The benefit of removing the deprecated
code obviously reduced the maintanance burder a bit. But is is really
that much? OTOH, it disables features that are being used or developed
in a bunch of important projects. It seems very premature to take this
step for F41, i.e. sometime within the next two—three months. It seems
that the ecosystem isn't ready.

The tradeoff for CentOS 10 is different: the first release is still
a while away and most people will not jump onto the 10.0 release anyway.
By the time CentOS is used in anger, the ecosystem might be ready.
This is one of the cases where using Fedora as a pre-release for CentOS
as a pre-release for RHEL is detrimental to Fedora.

> == How To Test ==
> OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40.
> Applications relying on the ENGINE API can't be built but still work.

That's incompatible with package rebuilds…

An acceptable approach would be to split out the headers to a separate
-devel file, e.g. openssl-engine-devel, mark it as Provides: deprecated().
Existing packages which need the engine headers can adjust to use the
new header and new packages are prevented by the Packaging Guidelines
from adding a dependency on deprecated packages.

Zbyszek
--
___
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

[Bug 2272636] perl-SDL-2.548-22.fc41 FTBFS with SDL2-2.30.1: t/core_events.t fails: Can't use an undefined value as a subroutine reference during global destruction

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

Petr Pisar  changed:

   What|Removed |Added

Summary|perl-SDL-2.548-22.fc41  |perl-SDL-2.548-22.fc41
   |FTBFS: t/core_events.t  |FTBFS with SDL2-2.30.1:
   |fails   |t/core_events.t fails:
   ||Can't use an undefined
   ||value as a subroutine
   ||reference during global
   ||destruction



--- Comment #2 from Petr Pisar  ---
This is indeed triggered by upgrading SDL2. SDL2-0:2.28.5-3.fc40.x86_64 does
not reproduce it.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272636

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272636%23c2
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2272636] perl-SDL-2.548-22.fc41 FTBFS: t/core_events.t fails

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



--- Comment #1 from Petr Pisar  ---
Verbose output of the test:

$ prove -b -v t/core_events.t
t/core_events.t ..
ok 1 - SDL::Events->can(...)
ok 2 - SDL::Event->can(...)
[...]
ok 692 - [joystick_event_state] return SDL_IGNORE correctly
ok 693 - [joystick_event_state] return SDL_ENABLE took SDL_QUERY
ok 694 - [joystick_event_state] return SDL_IGNORE correctly
ok 695 - [joystick_event_state] return  SDL_IGNORE took SDL_QUERY
ok 696 # skip Turn SDL_GUI_TEST on
ok 697 - Are we still alive? Checking for segfaults
1..697
Can't use an undefined value as a subroutine reference during global
destruction.
Dubious, test returned 22 (wstat 5632, 0x1600)
All 697 subtests passed 
(less 1 skipped subtest: 696 okay)


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272636

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272636%23c1
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2272636] New: perl-SDL-2.548-22.fc41 FTBFS: t/core_events.t fails

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

Bug ID: 2272636
   Summary: perl-SDL-2.548-22.fc41 FTBFS: t/core_events.t fails
   Product: Fedora
   Version: rawhide
   URL: https://koschei.fedoraproject.org/package/perl-SDL
Status: NEW
 Component: perl-SDL
  Assignee: hdego...@redhat.com
  Reporter: ppi...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: hdego...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com
Blocks: 2260875 (F41FTBFS,RAWHIDEFTBFS)
  Target Milestone: ---
Classification: Fedora



perl-SDL-2.548-22.fc41 fails to build in Fedora 41 because a test fails:

t/core_error.t .. ok
Can't use an undefined value as a subroutine reference during global
destruction.
t/core_events.t . 
Dubious, test returned 22 (wstat 5632, 0x1600)
All 697 subtests passed 
(less 1 skipped subtest: 696 okay)

A difference between passing and failing build root is at
. An upgrade of SDL2 from
2.28.5-3.fc40
to 2.30.1-1.fc41 is suspicious.



Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=2260875
[Bug 2260875] Fedora 41 FTBFS Tracker
-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2272636

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202272636%23c0
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-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/perl-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

2024-04-02 Thread Lennart Poettering

On Sa, 30.03.24 13:18, Gordon Messmer (gordon.mess...@gmail.com) wrote:

> On 2024-03-30 02:37, Richard W.M. Jones wrote:
> > (3) We should have a "security path", like "critical path".
> >
> > sshd is linked to a lot of libraries:
>
>
> I really don't want to start a systemd thread, but... the xz, lz4, and zstd
> libraries are pulled in by libsystemd, merely so that sshd can call
> "sd_notify" 
> (https://src.fedoraproject.org/rpms/openssh/blob/rawhide/f/openssh-7.4p1-systemd.patch),
> which raises a couple of questions.
>
> The first one that comes to mind is: Is the increased attack surface
> incurred by linking to these additional libraries worth the value provided
> by calling "sd_notify", or should that patch be dropped to improve sshd
> security?

As discussed elsewhere: these deps are now dlopen() in systemd git
main. So they are basically gone, unless you actually use one of the
API calls that need the code.

> The second is: Is libsystemd too large?  I could very easily be misreading
> it, but it looks like at least some of src/libsystemd/sd-journal is used by
> journald, including the compression bits.  Do those really belong in
> libsystemd?

There are various programs that use sd-journal to read journal
files. It's after all *the* place to you get your logs from these
days. And journal files can be compressed. We only use one compressor
when writing, but we have changed the compression library
(i.e. nowadays use zstd), and need to provide read
compatibility. Hence the other compression libs.

> If they need to be shared components, could the journald
> components be split out to reduce the size of libsystemd?  (That is, to
> avoid linking to the compression libs?)

This creates many other problems. For an explanation see the various
comments here: https://github.com/systemd/systemd/issues/32028

Also, I don't think we should get hung up too much on the libsystemd
thing. I know people like to hit on systemd, but the attacker could
have used various other vehicle libs for their goal, too. I mean, sshd
uses PAM, and that pull in variety of things through its modules, and
that's just very hard to properly review even when one just focusses
on the default PAM config on Fedora.

Lennart

--
Lennart Poettering, Berlin
--
___
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: Fedora Linux 40 Final Freeze

2024-04-02 Thread Jakub Jelinek

On Tue, Apr 02, 2024 at 12:33:04PM +0530, Samyak Jain wrote:
> Today, 2024-04-02, is an important day on the Fedora Linux 40 schedule
> [1], with significant cut-offs.
> 
> Today we have the Final Freeze [2] which starts at 14:00 UTC. This means
> that only packages that fix accepted blocker or freeze exception bugs
> [3][4][5] will be marked as 'stable' and included in the Final composes.

Will the currently testing->stable marked updates be still included in
stable without having to go through the exception/blocker process?

Jakub
--
___
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

2024-04-02 Thread Lennart Poettering

On Sa, 30.03.24 18:56, Fedora Development ML (devel@lists.fedoraproject.org) 
wrote:

> > In systemd git main, libsystemd is only linked to libc, libcap,
> > and libgcrypt + libgpg-error. A pull request to convert that that last
> > pair to dlopen is under review.
>
> That helps somewhat (it would have prevented this backdoor from working),
> but it also makes things even less transparent: How do we know whether some
> random sd_foobarify() function or some random foobard linked against
> libsystemd will (always or ever (and when?)) end up dlopening liblzma or
> not?
>
> Distribution packagers tend to dislike dlopen due to the hidden dependencies
> it introduces.

Well, this is certainly a valid point, but the solution is not to make
all deps hard ones. Instead, in order to just make these deps visible
I see multiple better alternatives:

1. teach Linux/ELF something inspired by MacOS's weak deps. i.e. allow
   ELF programs declare that some symbols shall be backed by some lib,
   but make it a weak dep that is only resolved on demand, and
   gracefully is set to NULL if the library cannot be found. If we had
   that, we'd stop using dlopen() for systemd's deps, since all we do
   is basically reimplement this concept manually.

2. without Linux/ELF supporting the above we could still teach systemd
   and other tools in similar situations to declare the dlopen deps
   they have in some ELF note or section, so that it can be processed
   by initrd generators, automatic dep generators in dpkg/rpm,
   ldd-like tools and everything else that wants this info. This would
   require some C macro magic, but could be added in probably just a
   few lines of codes added to relevant projects.

Lennart

--
Lennart Poettering, Berlin
--
___
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

* Gordon Messmer:

> Why doesn't dlopen() solve the problem?  As best I understand it,
> liblzma was able to steal one (or more) of the symbols from
> libcrypto.so.3 because it ran constructors at a point in time when the
> GOT was still writable.  After loading shared objects is complete,
> that table is made read-only.  If dlopen() is used after the program
> starts, then even if the library is loaded, it can't steal symbols in
> the table any more.

The rsa_pkcs1_ossl_meth variable that contains a function pointer to the
actual implementation resides in read-write memory:

static RSA_METHOD rsa_pkcs1_ossl_meth = {
"OpenSSL PKCS#1 RSA",
rsa_ossl_public_encrypt,
rsa_ossl_public_decrypt, /* signature verification */
rsa_ossl_private_encrypt,/* signing */
rsa_ossl_private_decrypt,
rsa_ossl_mod_exp,
BN_mod_exp_mont,/* XXX probably we should not use Montgomery
 * if e == 3 */
rsa_ossl_init,
rsa_ossl_finish,
RSA_FLAG_FIPS_METHOD,   /* flags */
NULL,
0,  /* rsa_sign */
0,  /* rsa_verify */
NULL,   /* rsa_keygen */
NULL/* rsa_multi_prime_keygen */
};

The missing “const” keyword is probably an oversight, but I don't think
it matters because the variable is not used directly.  All access
happens through deefault_RSA_meth:

static const RSA_METHOD *default_RSA_meth = _pkcs1_ossl_meth;

void RSA_set_default_method(const RSA_METHOD *meth)
{
default_RSA_meth = meth;
}

const RSA_METHOD *RSA_get_default_method(void)
{
return default_RSA_meth;
}

const RSA_METHOD *RSA_PKCS1_OpenSSL(void)
{
return _pkcs1_ossl_meth;
}

And that's clearly required to be read-write.  RSA_set_default_method is
a documented interface, too.  So I don't think GOT patching was required
to achieve the intended effect.

Furthermore, it's possible to undo the effect of RELRO with mprotect.

Using dlopen, liblzma would not have been loaded at run time, but it's
not clear if it had mattered because liblzma would still have been
loaded by RPM, both at build and install time.

Thanks,
Florian
--
___
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

F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

2024-04-02 Thread Aoife Moloney

Wiki - https://fedoraproject.org/wiki/Changes/OpensslDeprecateEngine

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
We disable building the packages using ENGINE API in OpenSSL without
breaking ABI.

== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbely...@redhat.com


== Detailed Description ==
We are going to deprecate OpenSSL engine support. Engines are not FIPS
compatible and corresponding API is deprecated since OpenSSL 3.0. The
engine functionality we are aware of (PKCS#11, TPM) is either covered
by providers or will be covered soon.

We don't plan to remove the API from libcrypto.so. We are going to
prevent creating the new packages dependent on OpenSSL ENGINE API and
remove ENGINE dependencies from the existing packages.

During discussion of the previous proposal - to completely remove the
ENGINE API - there were many relevant arguments why it shouldn't be
done. We agree with them but still want to deprecate the ENGINE
support to simplify removing it in the earliest release when it's
feasible.

== Feedback ==


== Benefit to Fedora ==
We get rid of deprecated functionality and enforce using up-to-date
API. Engine support is deprecated in OpenSSL upstream, and after
provider migration caused some deficiencies with engine support. No
new features will be added to engine. So we reduce maintenance burden
and potentially attack surface.

It follows approach planned for CentOS 10.

== Scope ==
* Proposal owners: maintainers of packages enumerated here:
https://clang.fedorapeople.org/c10s-engine-users/ plus probably owners
of some Fedora-only packages

For most of the packages the maintainers will just have to rebuild
their packages after the OpenSSL change lands in compose. For  several
packages some patches should be implemented to prevent compilation
errors.

* Other developers: -

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
This change probably requires mass-rebuild.


* Policies and guidelines: We need reject/modify packages providing
OpenSSL engines

* Trademark approval: N/A (not needed for this Change)


* Alignment with Community Initiatives:

== Upgrade/compatibility impact ==
None. Users will be encouraged to switch their configurations to use
providers instead but existing engines will continue working.



== How To Test ==
OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40.
Applications relying on the ENGINE API can't be built but still work.




== User Experience ==
Users will be encouraged to reconfigure systems to providers if they
use engines. No other changes are expected.


== Dependencies ==
In theory, all OpenSSL-dependent packages. In practice, only those
that explicitly use ENGINE api.




== Contingency Plan ==
Returning the engine header file to allow old applications to be built.

* Contingency mechanism: (What to do?  Who will do it?) rebuild
OpenSSL and dependent packages
* Contingency deadline: beta freeze?
* Blocks release? Yes


== Documentation ==
TBD



== Release Notes ==
TBD


-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

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

F41 Change Proposal: OpenSSL Deprecate Engine (system-wide)

2024-04-02 Thread Aoife Moloney

Wiki - https://fedoraproject.org/wiki/Changes/OpensslDeprecateEngine

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
We disable building the packages using ENGINE API in OpenSSL without
breaking ABI.

== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbely...@redhat.com


== Detailed Description ==
We are going to deprecate OpenSSL engine support. Engines are not FIPS
compatible and corresponding API is deprecated since OpenSSL 3.0. The
engine functionality we are aware of (PKCS#11, TPM) is either covered
by providers or will be covered soon.

We don't plan to remove the API from libcrypto.so. We are going to
prevent creating the new packages dependent on OpenSSL ENGINE API and
remove ENGINE dependencies from the existing packages.

During discussion of the previous proposal - to completely remove the
ENGINE API - there were many relevant arguments why it shouldn't be
done. We agree with them but still want to deprecate the ENGINE
support to simplify removing it in the earliest release when it's
feasible.

== Feedback ==


== Benefit to Fedora ==
We get rid of deprecated functionality and enforce using up-to-date
API. Engine support is deprecated in OpenSSL upstream, and after
provider migration caused some deficiencies with engine support. No
new features will be added to engine. So we reduce maintenance burden
and potentially attack surface.

It follows approach planned for CentOS 10.

== Scope ==
* Proposal owners: maintainers of packages enumerated here:
https://clang.fedorapeople.org/c10s-engine-users/ plus probably owners
of some Fedora-only packages

For most of the packages the maintainers will just have to rebuild
their packages after the OpenSSL change lands in compose. For  several
packages some patches should be implemented to prevent compilation
errors.

* Other developers: -

* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
This change probably requires mass-rebuild.


* Policies and guidelines: We need reject/modify packages providing
OpenSSL engines

* Trademark approval: N/A (not needed for this Change)


* Alignment with Community Initiatives:

== Upgrade/compatibility impact ==
None. Users will be encouraged to switch their configurations to use
providers instead but existing engines will continue working.



== How To Test ==
OpenSSL libcrypto.so exports the same ENGINE_* symbols as for f40.
Applications relying on the ENGINE API can't be built but still work.




== User Experience ==
Users will be encouraged to reconfigure systems to providers if they
use engines. No other changes are expected.


== Dependencies ==
In theory, all OpenSSL-dependent packages. In practice, only those
that explicitly use ENGINE api.




== Contingency Plan ==
Returning the engine header file to allow old applications to be built.

* Contingency mechanism: (What to do?  Who will do it?) rebuild
OpenSSL and dependent packages
* Contingency deadline: beta freeze?
* Blocks release? Yes


== Documentation ==
TBD



== Release Notes ==
TBD


-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2024-04-02 Thread Aoife Moloney

Wiki - https://fedoraproject.org/wiki/Changes/FedoraPlasmaWorkstation

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Switch the default desktop experience for Workstation to KDE Plasma.
The GNOME desktop is moved to a separate spin / edition, retaining
release-blocking status.

== Owner ==

* Names: [[User:joshstrobl | Joshua Strobl]], [[User:marcdeop | Marc
Deop i Argemí]], [[User:tdawson | Troy Dawson]], [[User:farchord |
Steve Cossette]], [[User:aleasto| Alessandro Astone]]
* Emails: jos...@buddiesofbudgie.org, marcd...@fedoraproject.org,
tdaw...@redhat.com, farch...@gmail.com, alea...@fedoraproject.org

== Detailed Description ==

With the release of Plasma 6, KDE Plasma has developed into a high
quality, well-regarded desktop experience.

=== Improved end user experience ===

Plasma has been at the forefront of creating a cohesive desktop
platform that empowers the user to have full ownership of their
computing experience.

Plasma provides this approachable, highly-flexible, user-extensible
experience with predictability across Plasma releases. Unlike other
desktop experiences such as GNOME Shell, the APIs leveraged by Plasma
applets / widgets have been more stable across “minor” Plasma
releases, reducing long-term user frustration and promoting a
healthier ecosystem for developers and users alike.

This extensibility additionally applies to the underlying window
manager, KWin, with effects and scripts that provide both utility and
personalization, such as:

* Automatically blocking compositing for full screen applications
* Fun effects such as window glitch and portals

Plasma provides a more traditional user experience that could be
viewed as being more approachable to everyday computing users, serving
as a smoother "on-ramp" to using Linux-based operating systems.
Alongside its wide breadth of personalization capabilities, it
provides an out-of-the-box desktop experience that is more predictable
than some of its counterparts. As an example, Plasma provides a system
tray for applications supporting StatusNotifierItem (e.g. Flameshot,
OBS Studio, VPN clients), which is not functionality supported by
default in GNOME Shell and requires an extension which may break
between releases.

=== Standardization support ===

The KDE community has a long heritage of collaborative standards
development and supporting capabilities that application developers
and users need for a productive experience.

KDE is heavily involved in the development of cross-desktop standards
and tools that benefit the larger open source desktop community. From
the XDG icon theme specification to D-Bus to StatusNotifierItems and
Wayland protocols, KDE has been front and center for evolving the
Linux desktop platform in a manner that benefits the wider community.

Many of the specifications and protocols in use today originate or are
heavily influenced by KDE, and KDE has continued to be a bastion of
innovation in a user-centric and community-centric manner.

Notably, the following recent Wayland protocols have been driven or
influenced by KDE:

* xdg-toplevel-drag (dragging tabs in and out of windows)
* content-type
* drm-lease (enable applications to selectively gain privileged
display device access)
* tearing-control (enable faster than display framerate refreshing, ie
no “vsync lock”)
* ext-idle-notify
* xdg-activation (enable notifications to bring a window to the
foreground on user activation)
* xdg-decoration (server side decorations, derived from KDE’s protocol)

There are several upcoming protocols being driven by KDE as well, such as:

* alpha-modifier (set alpha values for a surface)
* ext-blur (enable blur effect underneath a surface)
* xdg-toplevel-icon (enable applications to set window icons)
* ext-placement (allow application window positioning)
* window-id (consistent, uniform method window IDs)
* xdg-pip (picture in picture overlays)
* dbus-annotation (link D-Bus objects to surfaces)

This demonstrates that KDE works not to just enable new technologies
and features for Plasma Wayland, but they also do it in a way that
drives larger community adoption, success, and growth.

=== Wayland support ===

KDE Plasma offers the most advanced Wayland desktop experience today,
providing support for highly-demanded features, such as:

* Fractional scaling
* Color management
* Variable Refresh Rate for capable displays
* Support for optionally allowing legacy X11 applications to access
desktop resources
* Screensharing for legacy applications
* Global shortcut support for legacy applications
* Support for accessibility, including integration with the Orca screen reader
* Support for AR/VR displays

=== Industry support ===

KDE Plasma has been garnering wider industry support in consumer
products over the last couple

Fedora Linux 40 Final Freeze

2024-04-02 Thread Samyak Jain

Hi all,

Today, 2024-04-02, is an important day on the Fedora Linux 40 schedule
[1], with significant cut-offs.

Today we have the Final Freeze [2] which starts at 14:00 UTC. This means
that only packages that fix accepted blocker or freeze exception bugs
[3][4][5] will be marked as 'stable' and included in the Final composes.
Other builds will remain in updates-testing until the Final release is
approved, at which point the Final freeze is lifted and packages can
move to the 'updates' repository. Pending updates will be pushed before
the final release as zero-day updates.

Regards,
Samyak Jain
(fas/matrix: jnsamyak)
Fedora Release Engineering

[1] https://fedorapeople.org/groups/schedule/f-40/f-40-key-tasks.html
[2] https://fedoraproject.org/wiki/Milestone_freezes
[3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[5] https://qa.fedoraproject.org/blockerbugs/milestone/40/final/buglist
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-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-announce@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

2024-04-02 Thread Zbigniew Jędrzejewski-Szmek

On Tue, Apr 02, 2024 at 02:00:52AM -0700, Gordon Messmer wrote:
> On 2024-03-30 09:12, Neal Gompa wrote:
> > Note that dlopen() doesn't fix the problem of the giant libsystemd in
> > the first place. It just obfuscates the true dependency graph of
> > libsystemd.
> 
> 
> This isn't my area of expertise, but I am curious:
> 
> Why doesn't dlopen() solve the problem?  As best I understand it, liblzma
> was able to steal one (or more) of the symbols from libcrypto.so.3 because
> it ran constructors at a point in time when the GOT was still writable. 
> After loading shared objects is complete, that table is made read-only.  If
> dlopen() is used after the program starts, then even if the library is
> loaded, it can't steal symbols in the table any more.
> 
> Or do I misunderstand this entirely?

You understood correctly ;)

As you wrote, dlopen() is done after RELRO has taken effect.

Also, dlopen() is only called lazily when the required library is to
be used for the first time… So in this particular case, the program
could call sd_notify(), but no dlopen() call would be done.

Zbyszek
--
___
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

2024-04-02 Thread Richard W.M. Jones

On Tue, Apr 02, 2024 at 10:59:10AM +0200, Florian Weimer wrote:
> * Richard W. M. Jones:
> > In the xz case this wouldn't have been enough, it turns out we would
> > also have to delete m4/build-to-host.m4, which then autoreconf
> > regenerates.  I don't fully understand why that is.
> 
> I would expect that's what the serial number is for?  But that's just a
> guess.

Yes, in this case the attacker had set the serial number to 30, but
the latest upstream serial number was 3.  autoreconf won't replace the
file in this case unless it is deleted.  There really should be an
"always replace if you can" option in autoreconf.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
___
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

2024-04-02 Thread Neal Gompa

On Tue, Apr 2, 2024 at 4:59 AM Florian Weimer  wrote:
>
> * Richard W. M. Jones:
>
> > I'm not pretending these will solve everything, but they should make
> > attacks a little harder in future.
> >
> >
> > (1) We should routinely delete autoconf-generated cruft from upstream
> > projects and regenerate it in %prep.  It is easier to study the real
> > source rather than dig through the convoluted, generated shell script
> > in an upstream './configure' looking for back doors.
> >
> > For most projects, just running "autoreconf -fiv" is enough.
> >
> > Yes, there are some projects that depend on a specific or old version
> > of autoconf.  We should fix those.  But that doesn't need to delay us
> > from using autoreconf on many projects today.
>
> Not shipping the m4 files and other artifacts required for regenerating
> autoconf scripts is not exactly rare, unfortunately.  I have filed a
> bunch of bugs because it's my understanding that this incomplete source
> code is against Fedora policies, but in the end, there isn't much we can
> do about it.
>
> But I sympathize with this approach, we should build from sources as
> much as we can.  Maybe not regenerate everything in %prep though, this
> really belongs into %build.  It's invoking a compiler, after all.
>

We have a %conf stage for this purpose. We should start using it.



-- 
真実はいつも一つ！/ Always, there's only one truth!
--
___
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

2024-04-02 Thread Gordon Messmer


On 2024-03-30 09:12, Neal Gompa wrote:

Note that dlopen() doesn't fix the problem of the giant libsystemd in
the first place. It just obfuscates the true dependency graph of
libsystemd.



This isn't my area of expertise, but I am curious:

Why doesn't dlopen() solve the problem?  As best I understand it, 
liblzma was able to steal one (or more) of the symbols from 
libcrypto.so.3 because it ran constructors at a point in time when the 
GOT was still writable.  After loading shared objects is complete, that 
table is made read-only.  If dlopen() is used after the program starts, 
then even if the library is loaded, it can't steal symbols in the table 
any more.


Or do I misunderstand this entirely?
--
___
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