from:"Christopher"



On 01/04/2024 19.27, Kevin Fenzi wrote:

On Mon, Apr 01, 2024 at 05:07:13PM +, Christopher Klooz wrote:

On 31/03/2024 23.08, Kevin Fenzi wrote:

On Sun, Mar 31, 2024 at 10:30:23PM +0200, Leon Fauster via devel wrote:

Not sure, if it was already mentioned -> containers. I had here a toolbox
environment with F40. That I had not in my first actions
on the screen. The last state had 5.6.0-3 installed but not sure
if the previous release was also installed ...

You should pull the latest version and restart any containers you were
running.

kevin

I assume rawhide has been fixed, too? So that rawhide users also just need to 
follow the same instructions as F40? Or do they need to reinstall?

Yes. The downgrade was pushed out on friday along with the f40 one.


If possible, I would like to end the topic updates in Fedora Discussion 
tomorrow and suggest users that they can consider the issue solved once they 
conducted all suggested steps and thus stop following the topic anylonger, but 
for rawhide I still have the warning issued to not use it at this time. Is the 
rawhide issue still open?

No, it should have the same resolution as f40.

kevin

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

Re: xz backdoor



On 31/03/2024 23.08, Kevin Fenzi wrote:

On Sun, Mar 31, 2024 at 10:30:23PM +0200, Leon Fauster via devel wrote:

Not sure, if it was already mentioned -> containers. I had here a toolbox
environment with F40. That I had not in my first actions
on the screen. The last state had 5.6.0-3 installed but not sure
if the previous release was also installed ...

You should pull the latest version and restart any containers you were
running.

kevin


I assume rawhide has been fixed, too? So that rawhide users also just need to 
follow the same instructions as F40? Or do they need to reinstall?

If possible, I would like to end the topic updates in Fedora Discussion 
tomorrow and suggest users that they can consider the issue solved once they 
conducted all suggested steps and thus stop following the topic anylonger, but 
for rawhide I still have the warning issued to not use it at this time. Is the 
rawhide issue still open?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

On 01/04/2024 16.32, Michael Catanzaro wrote:

On Sun, Mar 31 2024 at 06:52:53 PM +00:00:00, Christopher Klooz
wrote:

"Fedora Linux 40 branched users (i.e. pre-Beta) likely received the potentially
vulnerable 5.6.0-2.fc40 build if the system updated between March 2nd and March 6th.
Fedora Linux 40 Beta users only using stable repositories are NOT impacted. Fedora Linux
39 and 38 users are also NOT impacted."

-> only pre-beta, not beta, affected
-> F40 beta using stable NOT impacted (without challenging the previously
distributed assumption that testing is disabled by default)

That's still the same false information, isn't it?

It looks correct to me. The bug was fixed prior to the final release of F40 beta, so
describing it as "pre-beta" makes sense. And people who used only the stable
repos were indeed not affected. The article later clarifies that updates-testing is
enabled by default (although it would be nicer to do this higher up rather than lower
down the page).

Interesting. I thought the below note about "testing = enabled by default" was already
mentioned before. I was only worried about the top section. The abstract decides if people keep
reading, and with the previously spread information, I had doubt that the sentence motivates people
to read further. So I assume the "stable repo not impacted" sentence suggests something
false given the previously established context (default = stable, not testing).

Concerning your argument that the bug was fixed prior to the beta release, I
answered on the Fedora Discussion topic [1] (to avoid duplication here) since I
am not sure if I understand what you mean (and what it implies for the majority
of users).

Btw, thanks for your elaborations and clarifications in the recent days ;)

[1]
https://discussion.fedoraproject.org/t/xz-lessons-learned-if-how-to-involve-fedora-magazine-in-cve-handling/111255/16
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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

On 31/03/2024 21.33, Sandro wrote:

On 31-03-2024 20:54, Christopher Klooz wrote:

On 31/03/2024 20.52, Christopher Klooz wrote:

On 31/03/2024 20.21, Michael Catanzaro wrote:

On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:

I'm really frustrated with our communication regarding this issue. Does anybody
know who can fix this?

The Fedora Magazine article has been fixed (thanks!).

"*Fedora Linux 40 branched users (i.e. pre-Beta) likely received the potentially
vulnerable /5.6.0-2.fc40/ build
<https://bodhi.fedoraproject.org/updates/FEDORA-2024-4417db3376> if the system updated
between March 2nd and March 6th*. Fedora Linux 40 Beta users only using stable repositories are
NOT impacted. Fedora Linux 39 and 38 users are also NOT impacted."

-> only pre-beta, not beta, affected
-> F40 beta using stable NOT impacted (without challenging the previously
distributed assumption that testing is disabled by default)

That's still the same false information, isn't it?

Justin just has shown up in discourse. I suggested to get in touch with you,
Adam or Kevin since he seemed to be convinced the article is fine as it is.
When I refresh the article, it still seems to be unchanged. Is the update you
mean already online Michael?

I clarified what's wrong with Justin in a DM on Matrix. He was on the same garden path as I was
regarding "Beta release" vs. "Final release".

There will be another update to the article.

-- Sandro
--

Given the issues we had in the recent days in the communications between Fedora
Magazine, a discussion if and/or how to use it in CVE handling has evolved in
Fedora Discussions. I have just moved this into a dedicated topic, in case you
want to add your perspectives:
https://discussion.fedoraproject.org/t/xz-lessons-learned-if-how-to-involve-fedora-magazine-in-cve-handling/111255
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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


On 31/03/2024 23.11, Kevin Fenzi wrote:

On Sun, Mar 31, 2024 at 08:55:37PM +, Christopher Klooz wrote:

The repo files should be the same on Fedora containers, so if the container is 
F40 and the testing repo is enabled, it might have installed the malicious 
build.

Right, if it was dnf updated during the time that the bad update was in
updates-testing.

Folks should pull the latest and restart.


Preemptively, I added yesterday to the Fedora Discussion topic that people 
shall also update their toolbox containers. I am not sure if a container can 
end up in a condition that is vulnerable (especially since it has no dedicated 
systemd), but I assume we do not know for sure at this time, and the package 
was available to toolbox if the testing was enabled on a F40 container (I 
assume there are already F40 containers available? Didn't verify).

Yeah, best to be safe and pull the latest that doesn't have the affected
build and rerun.

Yes, there are f40 containers available.

kevin

Great point. I adjusted the Fedora Discussion topic.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

On 31/03/2024 22.30, Leon Fauster via devel wrote:

Am 31.03.24 um 21:33 schrieb Sandro:

On 31-03-2024 20:54, Christopher Klooz wrote:

On 31/03/2024 20.52, Christopher Klooz wrote:

On 31/03/2024 20.21, Michael Catanzaro wrote:

On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro
wrote:

I'm really frustrated with our communication regarding this issue. Does anybody
know who can fix this?

The Fedora Magazine article has been fixed (thanks!).

-> only pre-beta, not beta, affected
-> F40 beta using stable NOT impacted (without challenging the previously
distributed assumption that testing is disabled by default)

That's still the same false information, isn't it?

I clarified what's wrong with Justin in a DM on Matrix. He was on the same garden path as I was
regarding "Beta release" vs. "Final release".

There will be another update to the article.

Not sure, if it was already mentioned -> containers. I had here a toolbox
environment with F40. That I had not in my first actions
on the screen. The last state had 5.6.0-3 installed but not sure
if the previous release was also installed ...

The repo files should be the same on Fedora containers, so if the container is
F40 and the testing repo is enabled, it might have installed the malicious
build.

Preemptively, I added yesterday to the Fedora Discussion topic that people
shall also update their toolbox containers. I am not sure if a container can
end up in a condition that is vulnerable (especially since it has no dedicated
systemd), but I assume we do not know for sure at this time, and the package
was available to toolbox if the testing was enabled on a F40 container (I
assume there are already F40 containers available? Didn't verify).

So I suggest to preemptively act with F40 toolboxes in the same way as with F40 if
testing was enabled. ->
https://discussion.fedoraproject.org/t/attention-malicious-code-in-current-beta-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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


On 31/03/2024 20.52, Christopher Klooz wrote:


On 31/03/2024 20.21, Michael Catanzaro wrote:

On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro 
 wrote:

I'm really frustrated with our communication regarding this issue. Does anybody 
know who can fix this?


The Fedora Magazine article has been fixed (thanks!).


"*Fedora Linux 40 branched users (i.e. pre-Beta) likely received the potentially 
vulnerable /5.6.0-2.fc40/ build 
<https://bodhi.fedoraproject.org/updates/FEDORA-2024-4417db3376> if the system updated 
between March 2nd and March 6th*. Fedora Linux 40 Beta users only using stable repositories are 
NOT impacted. Fedora Linux 39 and 38 users are also NOT impacted."

 -> only pre-beta, not beta, affected
 -> F40 beta using stable NOT impacted (without challenging the previously 
distributed assumption that testing is disabled by default)

That's still the same false information, isn't it?

Justin just has shown up in discourse. I suggested to get in touch with you, 
Adam or Kevin since he seemed to be convinced the article is fine as it is. 
When I refresh the article, it still seems to be unchanged. Is the update you 
mean already online Michael?
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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



On 31/03/2024 20.21, Michael Catanzaro wrote:

On Sun, Mar 31 2024 at 09:56:04 AM -05:00:00, Michael Catanzaro 
 wrote:

I'm really frustrated with our communication regarding this issue. Does anybody 
know who can fix this?


The Fedora Magazine article has been fixed (thanks!).


"*Fedora Linux 40 branched users (i.e. pre-Beta) likely received the potentially 
vulnerable /5.6.0-2.fc40/ build 
 if the system updated 
between March 2nd and March 6th*. Fedora Linux 40 Beta users only using stable repositories are 
NOT impacted. Fedora Linux 39 and 38 users are also NOT impacted."

 -> only pre-beta, not beta, affected
 -> F40 beta using stable NOT impacted (without challenging the previously 
distributed assumption that testing is disabled by default)

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

Re: xz backdoor


On 31/03/2024 16.56, Michael Catanzaro wrote:

On Sun, Mar 31 2024 at 12:55:23 PM +00:00:00, Christopher Klooz 
 wrote:

In case someone from the Fedora Magazine is in the devel mailing list and reads 
this:


I'm really frustrated with our communication regarding this issue. Does anybody 
know who can fix this?

If we don't know who can fix Fedora Magazine on a Sunday, maybe we should just 
take down the entire domain until tomorrow. Fedora Magazine is an authoritative 
source and a lot of people are trusting the wrong information that we're 
providing.

Thanks for complaining about this, Christopher.

Michael


I don't feel good to implement such means without consensus with other 
moderators, but given that this article keeps telling affected users that they 
are not affected while it spreads confusing/misleading information, I have 
changed the Fedora Discussion topic [1] to make clear about the issue with the 
Fedora Magazine article in the very beginning, and indirectly warn about it. 
For average users, Fedora Discussion is the major source next to the magazine 
afaik. I tried to formulate it accommodating, but it has to be clear that the 
article's information was not correct and now the update added another 
incorrect information (Kevin made clear that beta has testing enabled) while 
the previous incorrect information is not devaluated either.

I think the Fedora Discussion topic's content shall do it for now and satisfy 
the majority of users. I keep following here, but if there is any change/add I 
need to do on that page, feel free to send/CC me an email directly, or a 
message on discourse. I keep available at least until Thursday to update it 
regularly if necessary.

[1] 
https://discussion.fedoraproject.org/t/attention-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683

Chris
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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



On 30/03/2024 15.45, Michael Catanzaro wrote:

On Sat, Mar 30 2024 at 12:26:48 PM +00:00:00, Christopher Klooz 
 wrote:

 If I got Rich right, the malicious code is likely to be broken on F40,


No, that is not correct, as explained by [1] and [2]. We have already asked Red 
Hat to investigate and fix the blog post. This is still an evolving situation; 
apologies for the confusion as we sort this out.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/
[2] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/

Then we must have had some communication snafu regarding the Fedora Magazine 
article, because multiple people including myself flagged the incorrect 
statement there before the article was published. Hopefully we can get one this 
fixed, too.

Michael


In case someone from the Fedora Magazine is in the devel mailing list and reads 
this:

I am not sure if this is intended, but the article on the magazine already spread the false 
information that "testing" is disabled by default on F40 (this was also spread on 
LinkedIn - both have been already re-distributed into several channels), and now it says in the 
first section "Fedora Linux 40 Beta users only using stable repositories are NOT 
impacted".

I assume that users who already have the false information (which is already 
widely distributed) in mind do not feel corrected if they now read “Fedora 
Linux 40 Beta users only using stable repositories are NOT impacted”. They 
might simply come to the conclusion that they are not affected since they never 
enabled testing manually. The article does not correct the earlier information 
but leaves it as potentially valid.

I think you should make clear in the beginning that testing is enabled by 
default, and unless they changed it themselves, it has to be assumed to be 
enabled. With the false information spread already through many channels, I 
assume some people stop reading after the first section.

I just triggered Justin [1] but I am not sure if he is available at the moment. 
It would be cool if someone with privileges adjusts the article's first section.

[1] 
https://discussion.fedoraproject.org/t/attention-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683/41
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-03-30 Thread Christopher Klooz

On 30/03/2024 20.08, Sandro wrote:

On 30-03-2024 13:26, Christopher Klooz wrote:

I don't know how the assumption came up that F40 is only affected if users
opted in for testing, but that interpretation already ended up in the Fedora
Magazine and in the official linkedin post of Fedora (I already asked to
correct it).

I believe that statement is correct, since none of the xz-5.6.x packages ever
made it to F40 stable. The furthest they've got was updates-testing, which is
not enabled in the official Beta releases. However, if you installed F40 before
Beta was released, then updates-testing is enabled and users may have installed
the vulnerable package with a simple `sudo dnf upgrade`.

I admit the wording could be clearer in that opting in to updates-testing might
have been done on your behalf simply by installing F40 sometime between
branching and the Beta release. Some users might not be aware of that.

It may also help providing some simple instructions on how users can check if
they have any of the vulnerable versions installed in the article itself. I see
a comment to that extent.

So, the situation around F40 is somewhat murky since a lot of factors come into
play, but the statement that 5.6.x never made to F40 stable is correct[1] and
therefore users not having updates-testing enabled could not have installed
5.6.x without expressly enabling it.

[1] https://bodhi.fedoraproject.org/updates/?search=xz-5.6

I don't think this is right. Adam Williamson and Michael Catanzaro already
confirmed that F40 has testing enabled by default because it is pre-release. It
was also confirmed that some packages could have been installed on F40 variants
(see also the points of Michael and Richard here in the devel mailing list).
Michael and Adam also wrote some references in the Fedora Discussion topic [1]
about this.

It is obviously still an issue that is evolving and what seems clear now might
prove different later. But so far I tend to leave the discussion topic as it is
and ensure that F40 users expect being compromised and get informed to act
correspondingly with the suggested actions. However, I already added a point
how users can check if they have a malicious build.

[1]
https://discussion.fedoraproject.org/t/attention-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683/36
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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-03-30 Thread Christopher Klooz


On 30/03/2024 15.45, Michael Catanzaro wrote:

On Sat, Mar 30 2024 at 12:26:48 PM +00:00:00, Christopher Klooz 
 wrote:

 If I got Rich right, the malicious code is likely to be broken on F40,


No, that is not correct, as explained by [1] and [2]. We have already asked Red 
Hat to investigate and fix the blog post. This is still an evolving situation; 
apologies for the confusion as we sort this out.

[1] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/
[2] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BAO5S2VGTTWD6MHHCFHTAIAHZQFMOGAQ/

Then we must have had some communication snafu regarding the Fedora Magazine 
article, because multiple people including myself flagged the incorrect 
statement there before the article was published. Hopefully we can get one this 
fixed, too.

Michael


Thanks for clarifying. I have already deleted the Fedora Magazine link from the 
related Fedora Discussion topic [1] earlier, and now updated the rest. I re-add 
the magazine article when it was fixed, I pinged Justin already some hours ago, 
hopefully it gets updated soon.

[1] 
https://discussion.fedoraproject.org/t/attention-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-03-30 Thread Christopher Klooz


On 29/03/2024 22.10, Michael Catanzaro wrote:

On Fri, Mar 29 2024 at 08:16:55 PM +00:00:00, Richard W.M. Jones 
 wrote:

These are the exact builds which were vulnerable.  Note the tags are
all empty because Kevin untagged them last night, so you'll probably
need to cross-reference these with bodhi updates.


OK, I am going to ask Product Security to edit their blog post to remove the 
incorrect information. I will CC you on that request.

Thanks,

Michael


Confusion is increasing a little among different channels, and it would be nice 
if the RH blog post and the Red Hat CVE page would be updated, and maybe 
clarified: According to Adam Williamson, F40 is likely to have installed the 
packages because testing is enabled by default in pre-release. If I got Rich 
right, the malicious code is likely to be broken on F40, but F40 users still 
should update to be sure.

At the moment several "versions" and "assumptions" are rising that try to somehow make sense of the 
different publications (e.g., header of RH article "F41 and rawhide" -> headline in content "F40 and 
rawhide"). I don't know how the assumption came up that F40 is only affected if users opted in for testing, but that 
interpretation already ended up in the Fedora Magazine and in the official linkedin post of Fedora (I already asked to 
correct it).

Creating some clarification and unify our information provision can help to get rid of the current 
interpretations between "F40 - just don't care" and "F40 - the end of the world is 
coming" (sorry for the dramatization ;). I think one or two sentences in the RH blog post + RH 
CVE page should be fine to clarify, to avoid further confusion and to re-unify knowledge towards 
the facts, of course the same for the Fedora Magazine article but that's already underway.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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-03-29 Thread Christopher Klooz

On 29/03/2024 21.01, Richard W.M. Jones wrote:

On Fri, Mar 29, 2024 at 06:46:59PM +, Christopher Klooz wrote:

Yes, F40 beta is affected, along with rawhide, but not F38/F39.

https://discussion.fedoraproject.org/t/warning-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683

https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

https://access.redhat.com/security/cve/CVE-2024-3094

https://www.linkedin.com/posts/fedora-project_urgent-security-alert-for-fedora-41-and-fedora-activity-7179540438494629888-EH4d?utm_source=share_medium=member_desktop

It might be noted that the header of the RH article is wrong and refers to "F41 and rawhide",
whereas the RH article content is correct and refers to "F40 and rawhide". Other sources, including
the publication of Fedora Project (e.g., on linkedin), also refer to F40 and rawhide. However, the RH CVE
article also refers to "F41 and rawhide".

Can someone from RH check and change the RH article header and the RH CVE page content to
avoid confusion? I tend to assume that "F41 and rawhide" makes no sense at all
since the two are currently equal.

There was an F40 change that was vulnerable but it was in testing only
briefly. After disabling ifuncs we (accidentally) were not vulnerable
in F40. So the RH article is kind of correct.

I still recommend everyone updating to the Epoch: 1 package if they're
on F40 or F41.

Also if you're on F41 and/or think you might have installed the
vulnerable xz anywhere, note that the exploit has not been fully
analyzed and no one really knows what it could do. I'm currently
reinstalling a couple of machines from scratch and have regenerated
my SSH keys.

Rich.

Thanks for the clarifications and your quick responses to the issue!

However, the article could be still adjusted in some direction to avoid
confusion, e.g.:

page header: "Urgent security alert for Fedora Linux 41 and Fedora Rawhide users "
(-> 41)
page headline: "Urgent security alert for Fedora Linux 40 and Fedora Rawhide users
" (-> 40)

Not the most urgent problem at the moment of course, but maybe someone could adjust it at
some time. As Michael already mentioned, the term "F41" can be on itself a
little confusing at the moment.

Chris

On 29/03/2024 19.37, Barry wrote:

Has this shipped on f40 beta?

Barry

On 29 Mar 2024, at 18:08, Richard W.M. Jones wrote:

On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote:
Hi,

wow: https://www.openwall.com/lists/oss-security/2024/

I think at this point we clearly cannot trust xz upstream anymore and should
probably fork the project.

I kind of agree here, though it saddens me to say it. Any commit or
release by "Jia Tan" or "Hans Jansen" [1] is suspect until proven
otherwise, and those go back 2 or more years.

Rich.

[1] Putting quotes here because those are almost certainly not real
peoples' names.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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

--
___
devel mailing list -- d

Re: xz backdoor

2024-03-29 Thread Christopher Klooz


Yes, F40 beta is affected, along with rawhide, but not F38/F39.

https://discussion.fedoraproject.org/t/warning-malicious-code-in-current-pre-release-testing-versions-variants-f40-and-rawhide-affected-users-of-f40-rawhide-need-to-respond/110683

https://www.redhat.com/en/blog/urgent-security-alert-fedora-41-and-rawhide-users

https://access.redhat.com/security/cve/CVE-2024-3094

https://www.linkedin.com/posts/fedora-project_urgent-security-alert-for-fedora-41-and-fedora-activity-7179540438494629888-EH4d?utm_source=share_medium=member_desktop

It might be noted that the header of the RH article is wrong and refers to "F41 and rawhide", 
whereas the RH article content is correct and refers to "F40 and rawhide". Other sources, including 
the publication of Fedora Project (e.g., on linkedin), also refer to F40 and rawhide. However, the RH CVE 
article also refers to "F41 and rawhide".

Can someone from RH check and change the RH article header and the RH CVE page content to 
avoid confusion? I tend to assume that "F41 and rawhide" makes no sense at all 
since the two are currently equal.

Chris

On 29/03/2024 19.37, Barry wrote:

Has this shipped on f40 beta?

Barry


On 29 Mar 2024, at 18:08, Richard W.M. Jones  wrote:



On Fri, Mar 29, 2024 at 07:00:37PM +0100, Kevin Kofler via devel wrote:
Hi,

wow: https://www.openwall.com/lists/oss-security/2024/

I think at this point we clearly cannot trust xz upstream anymore and should
probably fork the project.

I kind of agree here, though it saddens me to say it.  Any commit or
release by "Jia Tan" or "Hans Jansen" [1] is suspect until proven
otherwise, and those go back 2 or more years.

Rich.

[1] Putting quotes here because those are almost certainly not real
peoples' names.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Login issues to lists.* and src.*? Any outages?

2024-02-26 Thread Christopher

On Mon, Feb 26, 2024 at 6:13 AM Michal Konecny  wrote:
[snip]
> It's usually good to wait for some time and try again. If the issue persists 
> you can open ticket on
> https://pagure.io/fedora-infrastructure/issues
>
> Michal

I did try over the course of a few hours. It wasn't until 3 days later
that I tried again and it worked.
But, filing an issue would have been difficult since I couldn't log in
to pagure.io either, since it uses the same authentication as the
others. I actually did try pagure.io, though I didn't mention it in my
initial email. But, it also didn't work.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Login issues to lists.* and src.*? Any outages?

2024-02-24 Thread Christopher

I don't think mine was a timeout error... it could have been, but I
don't remember. I thought it looked like an authentication failure,
rather than a timeout. But, it's working now, so I can't reproduce it.
:shrug:

On Sat, Feb 24, 2024 at 7:02 AM Barry Scott  wrote:
>
>
>
> On 22 Feb 2024, at 20:20, Christopher  wrote:
>
> Are there any known issues right now for logging in to 
> lists.fedoraproject.org or src.fedoraproject.org?
> Do we have a page for known outages?
>
> I can log in to accounts.fedoraproject.org, so I know my password and 2FA 
> token still works, but not to src.f.o or lists.f.o.
> I tried to disable my 2FA in there, to see if that had an effect, but it 
> wouldn't let me (I thought it was optional?)
>
> I'm still in the packager group in accounts.f.o (not inactive). So, I'm not 
> sure what the problem is.
>
> Is this a known issue? I haven't seen anything about this on the devel list 
> recently.
>
>
> I am seeing the same issue for https://discussion.fedoraproject.org
> When I click to login and try to use my FAS ID I end up on
> Here https://id.fedoraproject.org/login/pam
> with the error:
>
> Gateway Timeout
>
> The gateway did not receive a timely response from the upstream server or 
> application.
>
> But I can and did login successfully to https://accounts.fedoraproject.org
>
> Barry
>
>
>
> Thanks,
> Christopher
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Login issues to lists.* and src.*? Any outages?

2024-02-22 Thread Christopher

On Thu, Feb 22, 2024 at 4:01 PM Gary Buhrmaster
 wrote:
>
> On Thu, Feb 22, 2024 at 8:20 PM Christopher  
> wrote:
> >
> > Are there any known issues right now for logging in to 
> > lists.fedoraproject.org or src.fedoraproject.org?
> > Do we have a page for known outages?
>
> https://status.fedoraproject.org/
>
> It currently reports all systems operational
>

Yeah, I found that after asking. It also says it's updated manually,
so I'm not sure how reliable it is.


>
> > I can log in to accounts.fedoraproject.org, so I know my password and 2FA 
> > token still works, but not to src.f.o or lists.f.o.
> > I tried to disable my 2FA in there, to see if that had an effect, but it 
> > wouldn't let me (I thought it was optional?)
>
> Enrolling in 2FA is a one-way action
> (like Hotel California, you can never leave).


LOL, that's fine, as long as it's working... and it seems to be on
accounts.f.o, but not the others. I'm just really confused about why.
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Login issues to lists.* and src.*? Any outages?

2024-02-22 Thread Christopher

Are there any known issues right now for logging in to
lists.fedoraproject.org or src.fedoraproject.org?
Do we have a page for known outages?

I can log in to accounts.fedoraproject.org, so I know my password and 2FA
token still works, but not to src.f.o or lists.f.o.
I tried to disable my 2FA in there, to see if that had an effect, but it
wouldn't let me (I thought it was optional?)

I'm still in the packager group in accounts.f.o (not inactive). So, I'm not
sure what the problem is.

Is this a known issue? I haven't seen anything about this on the devel list
recently.

Thanks,
Christopher
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

2024-02-15 Thread Christopher Klooz


On 14/02/2024 17.35, Michel Lind wrote:

As a pandoc user, I'm happy to help with any reviews. Is there a list
where this tends to get posted, apart from devel?

Thanks,

Michel


Once the package needs a review, the request should be found here: 
http://fedoraproject.org/PackageReviewStatus/


Details of the roles of "contributor" and "reviewer" in the "package 
review process" can be found here: 
https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/ 
(based upon its history, I expect this page is kept updated but I don't 
know for sure)


According to the elaboration, you need to be in the FAS packager group, 
even for reviews.



On Fri, Feb 09, 2024 at 11:26:33PM +0800, Jens-Ulrik Petersen wrote:

I should also have added there's an increasing amount of technical debt
with the pandoc packaging - I guess I need to beg people to help with
package reviews: also reminded of our packaging (review) streamlining
discussion from Flock last year.

Jens

On Fri, 9 Feb 2024, 23:23 Jens-Ulrik Petersen,  wrote:


Hello I am here - thanks for contacting me.

I was hoping to cover this as part of my F40 Change, but unfortunately I
haven't gotten to it, so the Change is now at risk of being deferred to F41.

Nevertheless I will see what I can do about this for F40: maybe a backport
can also be done for F39.

Next time you could also comment on the relevant bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1996301  - that would be
appreciated.

Thanks, Jens

PS Special thanks to Neal Gompa for pinging me in Matrix. 


On Fri, 9 Feb 2024, 20:05 Christopher Klooz,  wrote:


I cannot reach the maintainer petersen (see mail below): The package
"pandoc" remains at 3.1.3 in Fedora, but pandoc is already at 3.1.11.1.
Among the updates since 3.1.3, there have been two security-critical
(including the medium CVE-2023-35936. Security fixes are in 3.1.4 & 3.1.6).

The actual risk is limited, but these should be updated nevertheless.

Does anyone know how to reach him by other means?

Regards,
Chris


 Forwarded Message 
Subject: Fedora package "pandoc" outdated and contains security
vulnerability
Date: Thu, 1 Feb 2024 15:55:09 +0100
From:py0...@posteo.net
To:peter...@fedoraproject.org

Hi petersen,

I am reaching out because of the package "pandoc", which you maintain.

I have seen that the package is still at version 3.1.3 [1] when I tried
to install it with dnf, whereas the current version is 3.1.11.1 [2]: is
this intended or an accident?

It has to be noted that the updates that have been added in the meantime
contain fixes for security vulnerabilities (at least CVE-2023-35936; I have
just roughly skimmed the changelogs). So at the moment, it seems the Fedora
build can be exploited by attackers in some circumstances [3] [4] because
it is still at 3.1.3.

Regards & thanks for maintaining,

Chris

[1]https://koji.fedoraproject.org/koji/packageinfo?packageID=11560

[2]https://hackage.haskell.org/package/pandoc  &
https://github.com/jgm/pandoc

[3]https://github.com/jgm/pandoc/releases?page=1

[4]https://github.com/jgm/pandoc/releases?page=2

--
___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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 todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/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 todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/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: http

Re: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

2024-02-10 Thread Christopher Klooz


On 09/02/2024 16.26, Jens-Ulrik Petersen wrote:

I should also have added there's an increasing amount of technical debt
with the pandoc packaging - I guess I need to beg people to help with
package reviews: also reminded of our packaging (review) streamlining
discussion from Flock last year.

Jens
Unfortunately, I couldn't attend last Flock, so I don't know the related 
discussion. But I will have a look on the current review guidelines in 
the next days, in order to check if this is a commitment I can reliably 
provide over time. Maybe I can support with this. I'll let you know if so.


On Fri, 9 Feb 2024, 23:23 Jens-Ulrik Petersen,  wrote:


Hello I am here - thanks for contacting me.

I was hoping to cover this as part of my F40 Change, but unfortunately I
haven't gotten to it, so the Change is now at risk of being deferred to F41.

Nevertheless I will see what I can do about this for F40: maybe a backport
can also be done for F39.

Next time you could also comment on the relevant bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1996301 - that would be
appreciated.

Thanks, Jens

PS Special thanks to Neal Gompa for pinging me in Matrix. 


On Fri, 9 Feb 2024, 20:05 Christopher Klooz,  wrote:


I cannot reach the maintainer petersen (see mail below): The package
"pandoc" remains at 3.1.3 in Fedora, but pandoc is already at 3.1.11.1.
Among the updates since 3.1.3, there have been two security-critical
(including the medium CVE-2023-35936. Security fixes are in 3.1.4 & 3.1.6).

The actual risk is limited, but these should be updated nevertheless.

Does anyone know how to reach him by other means?

Regards,
Chris


 Forwarded Message 
Subject: Fedora package "pandoc" outdated and contains security
vulnerability
Date: Thu, 1 Feb 2024 15:55:09 +0100
From: py0...@posteo.net
To: peter...@fedoraproject.org

Hi petersen,

I am reaching out because of the package "pandoc", which you maintain.

I have seen that the package is still at version 3.1.3 [1] when I tried
to install it with dnf, whereas the current version is 3.1.11.1 [2]: is
this intended or an accident?

It has to be noted that the updates that have been added in the meantime
contain fixes for security vulnerabilities (at least CVE-2023-35936; I have
just roughly skimmed the changelogs). So at the moment, it seems the Fedora
build can be exploited by attackers in some circumstances [3] [4] because
it is still at 3.1.3.

Regards & thanks for maintaining,

Chris

[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=11560

[2] https://hackage.haskell.org/package/pandoc &
https://github.com/jgm/pandoc

[3] https://github.com/jgm/pandoc/releases?page=1

[4] https://github.com/jgm/pandoc/releases?page=2

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

2024-02-10 Thread Christopher Klooz


Hi Jens,

Thanks for the information. Unfortunately, I didn't see the bugzilla ticket.

On 09/02/2024 16.23, Jens-Ulrik Petersen wrote:

Hello I am here - thanks for contacting me.

I was hoping to cover this as part of my F40 Change, but unfortunately I
haven't gotten to it, so the Change is now at risk of being deferred to F41.

Nevertheless I will see what I can do about this for F40: maybe a backport
can also be done for F39.

Next time you could also comment on the relevant bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1996301 - that would be
appreciated.

Thanks, Jens

PS Special thanks to Neal Gompa for pinging me in Matrix. 


On Fri, 9 Feb 2024, 20:05 Christopher Klooz,  wrote:


I cannot reach the maintainer petersen (see mail below): The package
"pandoc" remains at 3.1.3 in Fedora, but pandoc is already at 3.1.11.1.
Among the updates since 3.1.3, there have been two security-critical
(including the medium CVE-2023-35936. Security fixes are in 3.1.4 & 3.1.6).

The actual risk is limited, but these should be updated nevertheless.

Does anyone know how to reach him by other means?

Regards,
Chris


 Forwarded Message 
Subject: Fedora package "pandoc" outdated and contains security
vulnerability
Date: Thu, 1 Feb 2024 15:55:09 +0100
From: py0...@posteo.net
To: peter...@fedoraproject.org

Hi petersen,

I am reaching out because of the package "pandoc", which you maintain.

I have seen that the package is still at version 3.1.3 [1] when I tried to
install it with dnf, whereas the current version is 3.1.11.1 [2]: is this
intended or an accident?

It has to be noted that the updates that have been added in the meantime
contain fixes for security vulnerabilities (at least CVE-2023-35936; I have
just roughly skimmed the changelogs). So at the moment, it seems the Fedora
build can be exploited by attackers in some circumstances [3] [4] because
it is still at 3.1.3.

Regards & thanks for maintaining,

Chris

[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=11560

[2] https://hackage.haskell.org/package/pandoc &
https://github.com/jgm/pandoc

[3] https://github.com/jgm/pandoc/releases?page=1

[4] https://github.com/jgm/pandoc/releases?page=2

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Fwd: Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

2024-02-09 Thread Christopher Klooz


Thanks! :)

On 09/02/2024 13.18, Luna Jernberg wrote:

CCed his work email in case he looks there

-- Forwarded message -
Från: Christopher Klooz 
Date: fre 9 feb. 2024 kl 13:05
Subject: Unresponsive maintainer: petersen / Pandoc package not updated
since June 2023: Security vulnerability, CVE-2023-35936 (medium)
To: Development discussions related to Fedora https://koji.fedoraproject.org/koji/packageinfo?packageID=11560

[2] https://hackage.haskell.org/package/pandoc &
https://github.com/jgm/pandoc

[3] https://github.com/jgm/pandoc/releases?page=1

[4] https://github.com/jgm/pandoc/releases?page=2

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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

Unresponsive maintainer: petersen / Pandoc package not updated since June 2023: Security vulnerability, CVE-2023-35936 (medium)

2024-02-09 Thread Christopher Klooz

I cannot reach the maintainer petersen (see mail below): The package 
"pandoc" remains at 3.1.3 in Fedora, but pandoc is already at 3.1.11.1. 
Among the updates since 3.1.3, there have been two security-critical 
(including the medium CVE-2023-35936. Security fixes are in 3.1.4 & 3.1.6).


The actual risk is limited, but these should be updated nevertheless.

Does anyone know how to reach him by other means?

Regards,
Chris



 Forwarded Message 
Subject: 	Fedora package "pandoc" outdated and contains security 
vulnerability

Date:   Thu, 1 Feb 2024 15:55:09 +0100
From:   py0...@posteo.net
To: peter...@fedoraproject.org



Hi petersen,

I am reaching out because of the package "pandoc", which you maintain.

I have seen that the package is still at version 3.1.3 [1] when I tried 
to install it with dnf, whereas the current version is 3.1.11.1 [2]: is 
this intended or an accident?


It has to be noted that the updates that have been added in the meantime 
contain fixes for security vulnerabilities (at least CVE-2023-35936; I 
have just roughly skimmed the changelogs). So at the moment, it seems 
the Fedora build can be exploited by attackers in some circumstances [3] 
[4] because it is still at 3.1.3.


Regards & thanks for maintaining,

Chris

[1] https://koji.fedoraproject.org/koji/packageinfo?packageID=11560

[2] https://hackage.haskell.org/package/pandoc & 
https://github.com/jgm/pandoc


[3] https://github.com/jgm/pandoc/releases?page=1

[4] https://github.com/jgm/pandoc/releases?page=2
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Brasero can't create CD images in F39

2023-12-30 Thread Christopher Klooz


On 29/12/2023 17.31, Sergio Pascual wrote:

Hello, I would like to bring attention to this bug
https://bugzilla.redhat.com/show_bug.cgi?id=2250192

This problem prevents Brasero from creating CD images in F39.
Brasero complains about  "old version of cdrdao", but the version in F39 is
the latest (1.2.5).
It actually works if you force install  an older (1.2.4) cdrdao from F37.
There is also an open ticket about k3b, which likewise is caused by an 
error that relates to `cdrdao`: 
https://bugzilla.redhat.com/show_bug.cgi?id=2212471


Regards, Sergio

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

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

2023-12-24 Thread Christopher Klooz

With regards to the related discourse topic #22 [1] (and my previous 
comment here): If this is introduced, what do you think of adjusting the 
starting page for F40 in Firefox? Most users tend to first check their 
Internet (and related issues) by opening their default browser and check 
if it works or if they can use their preferred search engine to search a 
solution:

A small bold warning (and maybe a picture or two of how the problem 
manifests - e.g., the limited connectivity warning - to capture their 
attention) with a hint and a few pictures of which button to pull to 
disable the MAC randomization if they are affected negatively could be a 
good mitigation without increasing the stuff in the installer.

[1] 
https://discussion.fedoraproject.org/t/f40-change-proposal-wifi-mac-randomization-system-wide/99856/22

On 24/12/2023 11.19, Christopher Klooz wrote:

On 24/12/2023 04.45, Sam Varshavchik wrote:

Kevin Kofler via devel writes:

Sam Varshavchik wrote:

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

>
> Most recent Android phones, and iPhones do this by default.
>
> What they do is pin each randomized MAC address per AP. They're not
> randomizing MACs for each connect, but basically generate a 
randomized MAC

> for each AP known to the phone.

What is this actually good for? Any AP you connect to can still 
track you
this way, and anything further uplink should not get your MAC 
address to

begin with anyway (only your IP address).

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

The majority of privacy issues when it comes to tracking take place on 
higher layers. The providers that are able to collect massive amounts 
of information about you have no access to your MAC. E.g., when using 
Google services. If a hotel chain can track me throughout its hotels, 
it can get more information than otherwise. However, they still get 
much less information than most web services that make money with 
tracking, especially since most is HTTPS today. There is an advantage 
with MAC randomization, but it is a small one, and I am not convinced 
if it is worth the efforts: for both developers and the users who have 
to handle some issues - or beginners who possibly end up in a "denial 
of service" because they have no idea what the problem is and how to 
respond (if people get a new notebook, those who use filtering for 
whitelists/blacklists or content filters for problematic content, e.g. 
if they have kids, will likely understand that something has to be 
done, but this proposal is not a case where a new notebook or so is 
introduced - thus, non-advanced users might not be able to understand 
WHAT to do and thus remain with the issue; some examples are in [1]).

However, if there is a RFC that is already implemented by Apple, 
Microsoft and Android, I tend to change my mind and say let's keep 
consistency among operating systems: at least if the big three do it, 
I expect that vendors of hardware (for home routers and such) will 
respond to that also in favor of beginners (hopefully...). In any 
case, we then might at least ensure that users experience the issue on 
all systems roughly at the same time... That might serve as a small 
but existing mitigation.

[1] 
https://discussion.fedoraproject.org/t/f40-change-proposal-wifi-mac-randomization-system-wide/99856/15

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F40 Change Proposal: Wifi MAC Randomization (System Wide)

2023-12-24 Thread Christopher Klooz

On 24/12/2023 04.45, Sam Varshavchik wrote:

Kevin Kofler via devel writes:

Sam Varshavchik wrote:

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

>
> Most recent Android phones, and iPhones do this by default.
>
> What they do is pin each randomized MAC address per AP. They're not
> randomizing MACs for each connect, but basically generate a 
randomized MAC

> for each AP known to the phone.

What is this actually good for? Any AP you connect to can still track 
you

this way, and anything further uplink should not get your MAC address to
begin with anyway (only your IP address).

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

The majority of privacy issues when it comes to tracking take place on 
higher layers. The providers that are able to collect massive amounts of 
information about you have no access to your MAC. E.g., when using 
Google services. If a hotel chain can track me throughout its hotels, it 
can get more information than otherwise. However, they still get much 
less information than most web services that make money with tracking, 
especially since most is HTTPS today. There is an advantage with MAC 
randomization, but it is a small one, and I am not convinced if it is 
worth the efforts: for both developers and the users who have to handle 
some issues - or beginners who possibly end up in a "denial of service" 
because they have no idea what the problem is and how to respond (if 
people get a new notebook, those who use filtering for 
whitelists/blacklists or content filters for problematic content, e.g. 
if they have kids, will likely understand that something has to be done, 
but this proposal is not a case where a new notebook or so is introduced 
- thus, non-advanced users might not be able to understand WHAT to do 
and thus remain with the issue; some examples are in [1]).

However, if there is a RFC that is already implemented by Apple, 
Microsoft and Android, I tend to change my mind and say let's keep 
consistency among operating systems: at least if the big three do it, I 
expect that vendors of hardware (for home routers and such) will respond 
to that also in favor of beginners (hopefully...). In any case, we then 
might at least ensure that users experience the issue on all systems 
roughly at the same time... That might serve as a small but existing 
mitigation.

[1] 
https://discussion.fedoraproject.org/t/f40-change-proposal-wifi-mac-randomization-system-wide/99856/15

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

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

2023-12-23 Thread Christopher Klooz

I would like to avoid duplicates and unnecessary redundancy, but 
especially for the issue discussed below it might be worth to also 
review the discussion on discussion.fp.org -> I am not convinced if it 
is that easy for all users when it comes to existing network 
configurations / setups, especially for users without sophisticated 
knowledge of the technical background -> 
https://discussion.fedoraproject.org/t/f40-change-proposal-wifi-mac-randomization-system-wide/99856


Btw, does anyone know if this (in the practically-same manner) is really 
already introduced in Windows, Mac, Android by default? Globally? This 
question indirectly came up in the discussion.fp.org topic and might 
impact how far vendors of routers and comparable 
devices/systems/software already consider MAC randomization (in existing 
networks / network configurations and such) to avoid issues for average 
users.


Best,
Chris

On 21/12/2023 14.53, Neal Gompa wrote:

On Thu, Dec 21, 2023 at 8:52 AM Leigh Scott  wrote:

I'm -1 for this change, it shouldn't be enabled by default as it will cause 
issues for users using router mac filtering.

What this seems to state is that the MAC address would be unique for
each SSID, but once it's picked, it would be locked in. That should
still make router-level MAC filtering possible, since the MAC address
would be stable for that network.




--
真実はいつも一つ！/ 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

--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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 local meetup London - 2024 (likely January or February)

2023-12-07 Thread Christopher Klooz

Because not everyone is active on discourse, I thought it makes sense to 
link this here for people from the area in or close to London:


https://discussion.fedoraproject.org/t/local-meetup-london-2024/98029
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: DNF5: Checking signatures of packages installed out of a repository?

2023-11-14 Thread Christopher

On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro  wrote:
>
> On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher
>  wrote:
> > I think for the sake of security, it'd be better if this were on by
> > default, and you just had to specify the --nogpgcheck
> > For convenience, the error message should probably say "Error: GPG
> > check FAILED (try again with '--nogpgcheck' to ignore)"
> > I don't think this use case is so important that everybody's security
> > should be lowered to avoid the minor inconvenience of passing a simple
> > flag.
>
> Thing is, when manually installing RPMs that don't come from a
> repository, 98% of the time they are not expected to be signed by a GPG
> key that you have installed, so the check is expected to fail.

The failure indicates that the source and integrity of the RPM is
uncertain. The fact that the user is expected to make a conscious
decision to bypass it when they want to accept that risk, but to be
stopped if they don't want to accept that risk, is the whole point.
So, yes, the check is expected to fail under those circumstances.

As for how common those circumstances are, I just surveyed my Fedora
systems, and 100% of the RPMs I've manually installed, including some
pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as
my own that I've built, all are signed. In my personal experience,
it's rare to come across an unsigned RPM. You may have a different
experience, but the frequency isn't the point... the point is to
provide protection by default and user choice to override and accept
the risks. Right now, we have acceptance of risk by default instead of
protection.

> GPG check is just not the right thing to do in this case.

I disagree. I think it *is* the right thing to do to check, and offer
the option to skip the check. That gives users the choice to be
insecure if they want, but leaves the default secure.

> If we enable GPG checking when not appropriate,

I disagree that the failure implies that GPG checking isn't
appropriate. I think the fact that an un-bypassed check failed, in
response to an RPM from an unknown or untrusted source, is very
appropriate. The only time it would not be appropriate, in my opinion,
is if the user chose to bypass it.

> ***we will train users to reflexively ignore GPG errors.***

So, your position is: "don't train users to ignore GPG errors... we'll
ignore them for you" ?!?!

First, I don't agree that this will happen. I think it's more likely
that users who are lax with security will continue to be lax with
security, and users who aren't will pay attention to the failures and
use that as a signal to inform their acceptance of the risks. But
second, even if you're right, the worst case scenario here is the
scenario we already have as the default: the check being ignored by
the user is nearly the same as the check not being performed at all,
which is what's happening today. If you're concerned that GPG errors
will be ignored, I don't understand why you're not concerned with the
fact that the only reason why users aren't seeing those errors today
is because GPG checks aren't running at all! All the same security
risks are still there... including the risks for an invalid or
fraudulent signature when it is present on a local RPM, in addition to
the risks when the signature is missing... they're just being ignored
by default. You're worried about a situation where a user *might*
ignore security check errors... but I'm worried that they are
auto-ignored by the system, before the user even has a chance to take
them seriously.

>
> (We have already trained users to approve importing new GPG keys as
> long as they claim to be from Fedora, since this is required every
> Fedora release. This is bad enough.)

I don't agree with that either. I verify the signatures of Fedora keys
using https://fedoraproject.org/security and the keys of other repos I
use, and other users who care about security can do the same. I think
Fedora has done as good a job as one can expect, for the most part, in
trying to provide good security to those who care. But, of course,
users have to care first and do their part as well.

>
> GPG check makes sense when installing RPMs from a configured
> repository, not when manually installing RPMs from a filesystem path or
> URL.

Again, I completely disagree. The check protects against corrupt
and/or malicious software, and is one of the few steps the package
management system has to proactively prevent harm to the user's system
*before* the harm is done. Skipping these checks by default is bad for
software supply chain security, regardless of whether the supply chain
involves a repo or just an RPM. The signatures are in the RPM, and the
keys in the RPM database. The fact that it came from a repo or not is
completely irrelevant for good software supply chain security
defaults.

>
>

Re: DNF5: Checking signatures of packages installed out of a repository?

2023-11-14 Thread Christopher

On Tue, Nov 14, 2023 at 9:24 AM Petr Pisar  wrote:
>
> V Tue, Nov 14, 2023 at 08:16:39AM -0500, Christopher napsal(a):
> > On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek  wrote:
> > >
> > > I believe that one of the strong complains was related to not signed 
> > > packages. The use case is that when I build RPMs locally and then I 
> > > install them (see bellow).
> > >
> > > dnf install *.rpm --setopt=localpkg_gpgcheck=true
> > > ...
> > > Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > > Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not 
> > > signed
> > > Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > > Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not 
> > > signed
> > > Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> > > Error: GPG check FAILED
> > >
> > > Jaroslav
> >
> > I think for the sake of security, it'd be better if this were on by
> > default, and you just had to specify the --nogpgcheck
>
> Technical note: --nogpgcheck does not imply localpkg_gpgcheck=false. Both of
> them operate independently. That's another painful property of the current
> code and documentation.
>
> -- Petr

Why wouldn't this apply? Both the documentation for 'dnf' and
'dnf.conf' use similar terminology "gpgcheck", and the man page says
"Skip checking GPG signatures on packages (if RPM policy allows)." If
it doesn't apply, it seems like it definitely *should*, for
intuitiveness-sake. At the very least, if it doesn't apply, then the
documentation is seriously deficient.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: DNF5: Checking signatures of packages installed out of a repository?

2023-11-14 Thread Christopher

On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek  wrote:
>
> I believe that one of the strong complains was related to not signed 
> packages. The use case is that when I build RPMs locally and then I install 
> them (see bellow).
>
> dnf install *.rpm --setopt=localpkg_gpgcheck=true
> ...
> Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
> Error: GPG check FAILED
>
> Jaroslav

I think for the sake of security, it'd be better if this were on by
default, and you just had to specify the --nogpgcheck
For convenience, the error message should probably say "Error: GPG
check FAILED (try again with '--nogpgcheck' to ignore)"
I don't think this use case is so important that everybody's security
should be lowered to avoid the minor inconvenience of passing a simple
flag.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: DNF5: Checking signatures of packages installed out of a repository?

2023-11-05 Thread Christopher

On Sun, Nov 5, 2023 at 3:54 PM Samuel Sieb  wrote:
>
> On 11/2/23 06:36, Christopher wrote:
> > On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi  wrote:
> >>
> >> On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
> >>> It's also not clear when this option would take effect. Would it take
> >>> effect if I did `dnf install /path/to/local/file` or just when I did
> >>
> >> no, because that looks up that file in your repos and downloads the repo
> >> version of the package.
> >
> > That's not what I've seen. I've used this to explicitly install the
> > Google Chrome RPM before from a local path... before the Chrome repo
> > was set up, and it did not re-download the RPM from any repo. `dnf
> > install ./google-chrome-stable.rpm`. I remember this because it was
> > surprising to me that I didn't need to specify 'localinstall', that
> > regular 'install' just worked. Ever since, I've assumed that
> > 'localinstall' was just an alias for 'install' and didn't behave any
> > differently. Perhaps that assumption is wrong, but that appeared to be
> > the behavior I observed at the time.
>
> This was ambiguous and I think you were both considering different meanings.
>
> You can dnf install a local rpm file, but you can also give dnf a path
> to an actual file (e.g. /usr/bin/bash) that can be installed and dnf
> will find and install the package that contains it.
>
> # dnf install /usr/bin/bash
> Package bash-5.2.15-3.fc38.x86_64 is already installed.

I was definitely referring to /path/to/existing/local/package.rpm, but
I now understand the other behavior for
/path/to/missing/file/to/find/and/install.

Thank you for the clarification! That makes sense now.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: DNF5: Checking signatures of packages installed out of a repository?

2023-11-02 Thread Christopher

On Wed, Nov 1, 2023 at 5:39 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Wed, Nov 01, 2023 at 10:49:36AM -0700, Kevin Fenzi wrote:
> > On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
> > > On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi  wrote:
> > > >
> > > > FWIW, from what I can recall, yum used to check all packages, but this
> > > > resulted in tons of people complaining because they did not want it to
> > > > check their local packages. So, a localpkg_gpgcheck option was added and
> > > > set to false. dnf4 still has this option.
> > >
> > > I wasn't aware of that change in behavior. I can't find that option
> > > documented in the man page for dnf or any other readily available docs
> > > about dnf in my installation, or present in my dnf.conf file. I don't
> >
> > Odd. It's in the dnf.conf man page here in rawhide:
> >
> > "localpkg_gpgcheck
> >   boolean
> >
> >   Whether  to  perform  a  GPG signature check on local 
> > packages (packages in a
> >   file, not in a repository).  The default is False.  This 
> > option is subject to
> >   the active RPM security policy (see gpgcheck for more 
> > details).
> > "
> >
> > Looks like it was added to yum 13 years ago:
> > https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10fb59ccf3231e309115
>
> This is pretty badly documented. I'm pretty sure that most people will
> not guess that any URL qualifies as "in a file".
>
> The approach to security nowadays is much stricter than 13 years ago…
> I think we should revisit this decision.
>
> > > remember anybody ever complaining, certainly not "tons of people".
> >
> > This was 13-14 years ago.
> >
> > > Using local RPMs is a pretty rare thing. I can't imagine too many
> > > people complaining about this. It was never much of a burden, and to
> > > the extent that it was, it was a burden that was a worthwhile tradeoff
> > > for increased security.
> >
> > I'm just relaying the history here...
> >
> > > It's also not clear when this option would take effect. Would it take
> > > effect if I did `dnf install /path/to/local/file` or just when I did
> >
> > no, because that looks up that file in your repos and downloads the repo
> > version of the package.
> >
> > > `dnf localinstall /path/to/local/file`? What if I did `dnf
>
> My vote would be:
> 'dnf install /path/to/file' default to warn-but-allow (*)

I don't think any "warn-but-allow" option is sufficient. The warning
comes too late if the transaction is allowed to proceed. By the time
the user can react, the installation scripts could have already
corrupted the system due to installing a malicious or corrupted
package, and possibly in a way that prevents them from reacting at all
to the warning.

> 'dnf install https://some.url/' default to an enforcing check
>
> For files outside of a repo, the current set of keys registered
> with rpm should be used. A valid-signature-with-unknown-key must be
> rejected when the check is enforcing.
>
> If such fine-grained policy is not possible, then I think
> defaulting to requiring explicit --nogpgcheck would be better
> than status quo.
>
> (*) I think that 99% of the time when you're doing a local install
> like that, the package was built by the user and it's convenient
> to skip the check.

I don't know how common it is for people to create their own RPMs, but
that's necessarily going to be some subset of all Fedora users. I
suspect there are many more users who install RPMs downloaded directly
from others where these checks matter more (GPU drivers, Steam
repackaging from Valve's DEBs, Amazon WorkSpaces client repackage made
from Amazon's DEB using alien, Google Chrome initial installation RPM
that sets up the Google YUM repo, Adobe Acrobat RPM, etc.), and who
never build their own RPMs.

However, even for those who build their own RPMs, skipping this check
is only going to be convenient for those who don't sign their own
RPMs... which is a good practice and very easy to do. After all, these
signatures don't just protect by authenticating the source of the
package, but they also verify the package integrity to protect against
file corruption.

Whatever inconvenience there is for users who build their own RPMs to
add an explicit --nogpgcheck to a command-line, I think that's
negligible compared to the benefit to everybody to verify by default.
Perhaps the minor inconvenience will encourage those holdouts to adopt
a better security posture and start signing the RPMs they build
themselves

Re: DNF5: Checking signatures of packages installed out of a repository?

2023-11-02 Thread Christopher

On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi  wrote:
>
> On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
> > On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi  wrote:
> > >
> > > FWIW, from what I can recall, yum used to check all packages, but this
> > > resulted in tons of people complaining because they did not want it to
> > > check their local packages. So, a localpkg_gpgcheck option was added and
> > > set to false. dnf4 still has this option.
> >
> > I wasn't aware of that change in behavior. I can't find that option
> > documented in the man page for dnf or any other readily available docs
> > about dnf in my installation, or present in my dnf.conf file. I don't
>
> Odd. It's in the dnf.conf man page here in rawhide:
>
> "localpkg_gpgcheck
>   boolean
>
>   Whether  to  perform  a  GPG signature check on local packages 
> (packages in a
>   file, not in a repository).  The default is False.  This option 
> is subject to
>   the active RPM security policy (see gpgcheck for more details).
> "

You're right. I didn't see it before. I guess I wasn't looking in the
right place. After finding it, though, I will say, the options,
localpkg_gpgcheck, repo_gpgcheck, and gpgcheck, are all still a bit
confusing to me, as currently worded. In addition to revisiting the
defaults, I think there's room for improvement in these docs to make
them more approachable to end users of DNF.

>
> Looks like it was added to yum 13 years ago:
> https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10fb59ccf3231e309115
>
> > remember anybody ever complaining, certainly not "tons of people".
>
> This was 13-14 years ago.
>
> > Using local RPMs is a pretty rare thing. I can't imagine too many
> > people complaining about this. It was never much of a burden, and to
> > the extent that it was, it was a burden that was a worthwhile tradeoff
> > for increased security.
>
> I'm just relaying the history here...

Understood. Thanks.

>
> > It's also not clear when this option would take effect. Would it take
> > effect if I did `dnf install /path/to/local/file` or just when I did
>
> no, because that looks up that file in your repos and downloads the repo
> version of the package.

That's not what I've seen. I've used this to explicitly install the
Google Chrome RPM before from a local path... before the Chrome repo
was set up, and it did not re-download the RPM from any repo. `dnf
install ./google-chrome-stable.rpm`. I remember this because it was
surprising to me that I didn't need to specify 'localinstall', that
regular 'install' just worked. Ever since, I've assumed that
'localinstall' was just an alias for 'install' and didn't behave any
differently. Perhaps that assumption is wrong, but that appeared to be
the behavior I observed at the time.

>
> > `dnf localinstall /path/to/local/file`? What if I did `dnf
>
> yes.
>
> > localinstall remotepath:/to/remote/file`? All of these work, as it
> > seems "localinstall" and "install" both just work if given a URL,
> > local or remote.
>
> remote path just downloads the file and installs it, so it's the same as
> the last case.
>
> > This option seems poorly rolled out, unclear in function, and overall
> > bad for security.
>
> Well, nothing was rolled out, it's been that way for 13 years.

The way I was using the term "poorly rolled out", I just mean that it
seems the way it was implemented or deployed ("rolled out") was less
than ideal, regardless of when that occurred. Sorry if this wasn't
clear. It's possible we use these terms differently.

> Should it be revisited? Sure, and thats what this thread is for?

+1, and for what it's worth, my intent isn't to complain about
previous decisions, but to offer a critical perspective that can be
used constructively to inform future changes.

> >
> > >
> > > It's also worth noting that if you pass yum/dnf/dnf5 urls for the
> > > package(s) you want to install, it's not using a repo at all, it's
> > > downloading those packages and treating them as local packages.
> >
> > Is this meant to imply that it doesn't do checks by default whenever
> > you pass a URL?! That's even worse! From this user's perspective, a
> > URL pointing to a package in a repo, is just a more fully-qualified
> > way of specifying the shorthand package name. It seems very odd if
>
> But dnf has no way to know https://foo.bar/packagename is in a repo.
> If it is, you should enable the repo and install it with 'dnf install
> packagename'.

That's not clear, because some package managers actually

Re: DNF5: Checking signatures of packages installed out of a repository?

2023-11-01 Thread Christopher

On Wed, Nov 1, 2023 at 5:53 AM Paul Howarth  wrote:
>
> On Tue, 31 Oct 2023 12:48:31 -0400
> Christopher  wrote:
> > I'm actually a bit concerned about this thread, because I assumed DNF4
> > and DNF5 would check signatures by default today, and that it would
> > only skip if `--nogpgcheck` was passed as an option. If it sometimes
> > skips the GPG check without that flag, that seems like a serious
> > security bug to me. I would expect the same level of signature
> > verification for both `dnf install mypackage` and `wget mypackage.rpm
> > && dnf localinstall mypackage.rpm`.
> >
> > After all, there is no documented flag to force a GPG signature check,
> > only the flag to omit the check (`--nogpgcheck`). So, users really
> > have to rely on the default behavior of always checking GPG signatures
> > if they want DNF to check them. If DNF is not doing that, that's
> > really bad, because there's no way for users to force it to check
> > them.
>
> Maybe not using dnf, but you can check it using rpm directly:
>
> $ wget mypackage.rpm
> $ rpm --checksig mypackage.rpm

Yeah, that's why DNF is more convenient for this... the whole point of
using DNF to install a local file is for consistency of using the same
command as for repo packages, not manually altering the RPM database
outside of YUM/DNF (that results in a warning), and the expectation of
it performing the standard checks. If it's not doing those checks,
then I have to resort to doing that manually... but that undermines
the whole convenience of DNF being capable of handling local RPMs for
me. Why bother having that feature in DNF at all, if it doesn't add
any value for local packages?

>
> Regards, Paul.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/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: DNF5: Checking signatures of packages installed out of a repository?

2023-11-01 Thread Christopher

On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi  wrote:
>
> FWIW, from what I can recall, yum used to check all packages, but this
> resulted in tons of people complaining because they did not want it to
> check their local packages. So, a localpkg_gpgcheck option was added and
> set to false. dnf4 still has this option.

I wasn't aware of that change in behavior. I can't find that option
documented in the man page for dnf or any other readily available docs
about dnf in my installation, or present in my dnf.conf file. I don't
remember anybody ever complaining, certainly not "tons of people".
Using local RPMs is a pretty rare thing. I can't imagine too many
people complaining about this. It was never much of a burden, and to
the extent that it was, it was a burden that was a worthwhile tradeoff
for increased security.

It's also not clear when this option would take effect. Would it take
effect if I did `dnf install /path/to/local/file` or just when I did
`dnf localinstall /path/to/local/file`? What if I did `dnf
localinstall remotepath:/to/remote/file`? All of these work, as it
seems "localinstall" and "install" both just work if given a URL,
local or remote.

This option seems poorly rolled out, unclear in function, and overall
bad for security.

>
> It's also worth noting that if you pass yum/dnf/dnf5 urls for the
> package(s) you want to install, it's not using a repo at all, it's
> downloading those packages and treating them as local packages.

Is this meant to imply that it doesn't do checks by default whenever
you pass a URL?! That's even worse! From this user's perspective, a
URL pointing to a package in a repo, is just a more fully-qualified
way of specifying the shorthand package name. It seems very odd if
passing a fully-qualified path to a remote package results in less
security than specifying the (possibly ambiguous) shortname for a
package that DNF resolves via NVR.

>
> 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: DNF5: Checking signatures of packages installed out of a repository?

2023-10-31 Thread Christopher

On Tue, Oct 31, 2023 at 1:38 PM Vít Ondruch  wrote:
>
>
> Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a):
> > Hello,
> >
> > DNF5 got a complaint
> >  that "dnf 
> > update
> > https://...; skips verifying package signatures:
> >
> >  $ sudo dnf update 
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> >  
> > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
> >  [...]
> >  Warning: skipped PGP checks for 2 package(s).
> >
> > A DNF5 developer confirmed that old DNF4 does not verify signatures too.
> > The verification happens only for packages comming from a repository. Why 
> > DNF5
> > looks bad is because it actually prints the warning and thus keeps the user
> > better informed.
> >
> > The nonchecking behavior probably exists to make installing local packages
> > easy. If DNF5 would insist on checking the signatures, Fedora users would 
> > have
> > to pass --no-gpgchecks option to their "dnf5" commands to override the new
> > default, or start signing their packages. As always security is not easy.
> >
> > Because this an old behavior and some users probably depend on it, enabling
> > the verification for all cases looks like an abrupt change.
> >
> > I would would like to hear your opinion: Should DNF5 start verifying all
> > packages? Should DNF5 keep ignoring signatures for out-of-repository 
> > packages?
> > Or should rather narrow the verification skip to packages from a local file
> > system? Any other options?
>
>
> Or maybe verify what it can and report the packages which can't be
> verified? You can notice that I was actually installing singed packages.
>
> But I would (probably) not mind to explicitly specify `--no-gpgcheck`. I
> still would swear this used to be needed, that is why I try to install
> the signed packages.

I could have sworn the same thing. I think that it should be an error
if any package (it doesn't matter if it is local or not) cannot be
verified, unless `--nogpgcheck` is specified. This seems like the only
secure-by-default option. No RPM should be allowed to be installed if
it can't be verified, unless the user explicitly allows it. If less
secure options are provided (such as only providing a warning message
or skipping verification of local RPMs), then an option must be
provided to force the secure-behavior to prevent the installation of
any RPMs that haven't been verified (something like
`--requiregpgcheck`). But my strong preference is that it require GPG
checks by default. That is the behavior that is implied by the
existence of the `--nogpgcheck` flag and the non-existence of any
other related flags.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: DNF5: Checking signatures of packages installed out of a repository?

2023-10-31 Thread Christopher

On Tue, Oct 31, 2023 at 11:57 AM Petr Pisar  wrote:
>
> V Tue, Oct 31, 2023 at 04:32:09PM +0100, Fabio Valentini napsal(a):
> > On Tue, Oct 31, 2023 at 4:24 PM Petr Pisar  wrote:
> > >
> > > Hello,
> > >
> > > DNF5 got a complaint
> > >  that "dnf 
> > > update
> > > https://...; skips verifying package signatures:
> > >
> > > $ sudo dnf update 
> > > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm
> > >  
> > > https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm
> > > [...]
> > > Warning: skipped PGP checks for 2 package(s).
> > >
> > > A DNF5 developer confirmed that old DNF4 does not verify signatures too.
> > > The verification happens only for packages comming from a repository. Why 
> > > DNF5
> > > looks bad is because it actually prints the warning and thus keeps the 
> > > user
> > > better informed.
> > >
> > > The nonchecking behavior probably exists to make installing local packages
> > > easy. If DNF5 would insist on checking the signatures, Fedora users would 
> > > have
> > > to pass --no-gpgchecks option to their "dnf5" commands to override the new
> > > default, or start signing their packages. As always security is not easy.
> > >
> > > Because this an old behavior and some users probably depend on it, 
> > > enabling
> > > the verification for all cases looks like an abrupt change.
> > >
> > > I would would like to hear your opinion: Should DNF5 start verifying all
> > > packages? Should DNF5 keep ignoring signatures for out-of-repository 
> > > packages?
> > > Or should rather narrow the verification skip to packages from a local 
> > > file
> > > system? Any other options?
> >
> > I wonder - how would DNF (4 or 5 doesn't matter) know how to check that at 
> > all?
> > I mean, if the package isn't associated with a repository (like
> > installing an RPM directly), which GPG key should it even be checked
> > against?
> >
> Against any key already existing in an RPM database (rpm -qa | grep 
> gpg-pubkey).

Does DNF use the repository to verify GPG sigs now? If so, that seems
weird. I would assume they just check against the existing keys in the
RPM database, like Petr said.

I'm actually a bit concerned about this thread, because I assumed DNF4
and DNF5 would check signatures by default today, and that it would
only skip if `--nogpgcheck` was passed as an option. If it sometimes
skips the GPG check without that flag, that seems like a serious
security bug to me. I would expect the same level of signature
verification for both `dnf install mypackage` and `wget mypackage.rpm
&& dnf localinstall mypackage.rpm`.

After all, there is no documented flag to force a GPG signature check,
only the flag to omit the check (`--nogpgcheck`). So, users really
have to rely on the default behavior of always checking GPG signatures
if they want DNF to check them. If DNF is not doing that, that's
really bad, because there's no way for users to force it to check
them.

>
> -- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: An update on RHEL moving to issues.redhat.com

2023-09-14 Thread Christopher Klooz

It used to be different, but since GitLab changed their UI, I also would 
no longer choose it over alternatives (so, unfortunately: +1 for the UX 
mess & the preference for alternatives). The remaining advantage of 
GitLab is the time-effective drag/drop issue board, but that cannot 
balance the remaining mess... However, pagure has imho its own UX mess 
at some places, depending on what it is used for (while GitHub does not 
follow security best-practices in some respects)... My personal 
preference are gitea-based services, such as codeberg or so.


On 9/14/23 15:43, Peter Boy wrote:



Am 14.09.2023 um 14:50 schrieb Fabio Valentini :

Personally, I find the Pagure UI (and GitHub) to be much cleaner and
easier to navigate than the UX mess that is GitLab …

+++1





--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST /UTC+2)

Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Potential (security) issue for beginners/non-experts when release is End Of Life: Fedora doesn’t consider the behavior of beginners/non-experts sufficiently

2023-08-11 Thread Christopher Klooz

The below is a duplicate from discourse (I suggest to focus the 
discussion there): 
https://discussion.fedoraproject.org/t/potential-security-issue-for-beginners-non-experts-when-release-is-end-of-life-fedora-doesnt-consider-the-behavior-of-beginners-non-experts-sufficiently/87311/1 



I just became aware of another topic from a user who elaborates their 
problem and “by the way” mentions to use Fedora 35. The user provides 
this information in order to give an overview of his system 
configuration and thus does not consider this as part of the problem.


I have seen many of these topics over time, and I guess there are many 
more users out there who use obsoleted Fedora releases (the less 
experienced they are, the more they are likely to end up with obsoleted 
releases, and the less likely they are to end up on ask.fedora so that 
we can make them aware).


We officially want to make Fedora usable for average users (or 
beginners), but many (if not most) average users deploy their systems in 
a “fire and forget” manner: once they made it work, they maybe enable 
updates and such and then they no longer care if everything *seems* to 
work fine.


I assume that many of these users are not aware that they no longer 
receive updates, which can be dangerous.


First of all, I don’t use my Fedora installations until their /end of 
life/, so I don’t know if we have any means in place that shall make 
users aware once their release reaches /end of life/?


*If not*, does it make sense to add some means?

If we promote Fedora for average users/beginners, we have to also 
consider their behavior.


On one hand, it would be cool to make them a month or two before /end of 
life/ aware with a warning message that automatically forwards them to 
the GUI upgrade with a click and also allows them to click “warn me 
again tomorrow” or such.


On the other hand, more easy to implement solutions like that of Tails 
could be sufficient solutions, too: once the Tails ISO image is started 
(live system) and online, it checks if there are new images available. 
If so, it opens a warning window that makes the user aware that this 
image should no longer be used and shows a link and a short elaboration 
of how to get the new one.


Of course there are alternatives, too. Even an apparent bullet point on 
getfedora.org  would be a good first step (we 
could link it to Fedora being always up to date with most modern 
technologies, to link it to something positive). In either case, I think 
a short discussion of this makes sense.


This also applies to all Spins.


Best,
Chris
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: [Question] how to make Fedora linux os ?

2023-07-16 Thread Christopher

On Sun, Jul 16, 2023 at 7:30 AM Kevin Kofler via devel
 wrote:
>
> Miao, Jun wrote:
> > Hi Guys,
>
> First of all, we are not all guys. (I happen to be one though.)

I would advise not to get too picky about this. The term "guys" isn't
necessarily gender-specific. In its plural form, it has basically
replaced "folks" in many English dialects, and holds the same
non-gendered meaning. The antonyms, "guy" and "gal" have largely
fallen out of favor in English, with the latter being quite rare, and
the former's plural form evolving into a non-gendered usage, similar
to "dude(s.)" and "dudes(pl.)" being used in non-gendered ways. While
I think it's a good idea to use gender-neutral language when gendered
language isn't needed, this one actually is pretty gender-neutral
already, at least in the way many people use it. So, I recommend not
reading too much into casual greetings like this. Getting too picky
runs the risk of polarizing people and making it harder to make
changes for the better where it matters. Assuming good intentions, it
seems like the author intended this in the common, modern,
non-gendered plural form to me.

>
> > AFAIK, the Yocto Project is an open source collaboration project that
> > provides tools, templates, and methods to help developers create custom
> > Linux-based systems for embedded devices.
> >
> > My confusion is that:
> >
> >   1.  what`s the tool to make our Fedora Linux 38 released like Yocto?
>
> There is more than one tool in use. The main build tool is Koji, but it
> depends on other underlying tools such as Mock, DNF, RPM, etc. Also keep in
> mind that in Fedora, all binaries are natively compiled, not cross-compiled
> as in Yocto. I.e., the rpmbuild process needs to run on a (real or emulated)
> CPU of the architecture for which you want to build the package. RPMs do not
> typically support cross-compilation.

When I saw the original post, I was interested to see what responses
it would trigger. I must admit that this one is a bit disappointing.
While I've been building RPMs for Fedora for awhile now, one of the
things that has eluded me is that the Fedora OS composes seem to be
very opaque to me. I know enough to understand that Koji tags rpm
builds from individual buildroots, but from there, the process to
build the repos and the installation media, or how the buildroots are
created in the first place for Koji, or any other weirdness involved
in the construction of the OS as a whole from the individual RPM
builds, all of that seems opaque to me. I think it'd be great if there
was an up-to-date and detailed step-by-step guide for how to build a
Fedora release. Such documentation should be detailed enough that one
could stand up their own fork of the Fedora OS... not because we want
to encourage that... but because that's the level of detail that I
think is needed to allow volunteers to step in and get involved, as
the current folks move on, due to retirement, death, boredom, or
whatever. If such documentation already exists, I don't know where it
could be found.

Do you know of any such detailed documentation, step-by-step
instructions, or maybe slides/presentations on the compose process or
overall Fedora OS build systems?

>
> >   2.  And Centos ?
>
> The only CentOS that is left is CentOS Stream, which (as far as I know) also
> uses Koji.
>
> The CentOS successors such as Rocky Linux and AlmaLinux are free to either
> also use Koji or use their own tools, or a combination. E.g., Rocky Linux
> has developed Peridot.
>
> >   3.  And Ubuntu ?
>
> Ubuntu has its own completely different tooling built around Debian's
> tooling and Canonical's Launchpad platform.
>
> 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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-12 Thread Christopher Klooz via devel

Matt has started a poll with regards to the community's preferences 
about the topic:


https://discussion.fedoraproject.org/t/straw-poll-on-your-preferences-about-opt-in-opt-out-for-possible-data-collection/85675/2 



On 7/12/23 12:37, Eike Rathke wrote:

Hi,

On Tuesday, 2023-07-11 08:17:07 -0500, Michael Catanzaro wrote:


I think what happens is: somebody (anybody) can report a post, if it gets
enough reports it gets proactively hidden before a moderator can review it.
Do our moderators eventually review such posts to ensure they're truly
inappropriate? Seems clear that the post is question should not have been
hidden.

According to https://mastodon.social/@decathorpe/110688949866653898
Fabio even (re-)approved the post to unhide it and then apparently some
moderator hid it again..
https://mastodon.social/@decathorpe/110692221789994477

It's time to declare a thread dead when moderator wars start. And it
shows that Discourse is the wrong medium to discuss controversial
proposals.

   Eike


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: F40 Change: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)

2023-07-12 Thread Christopher Klooz via devel

Matt has started a poll with regards to the community's preferences 
about the topic:


https://discussion.fedoraproject.org/t/straw-poll-on-your-preferences-about-opt-in-opt-out-for-possible-data-collection/85675/2

On 7/12/23 12:37, Eike Rathke wrote:

Hi,

On Tuesday, 2023-07-11 08:17:07 -0500, Michael Catanzaro wrote:


I think what happens is: somebody (anybody) can report a post, if it gets
enough reports it gets proactively hidden before a moderator can review it.
Do our moderators eventually review such posts to ensure they're truly
inappropriate? Seems clear that the post is question should not have been
hidden.

According to https://mastodon.social/@decathorpe/110688949866653898
Fabio even (re-)approved the post to unhide it and then apparently some
moderator hid it again..
https://mastodon.social/@decathorpe/110692221789994477

It's time to declare a thread dead when moderator wars start. And it
shows that Discourse is the wrong medium to discuss controversial
proposals.

   Eike


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: LXQt Spin: packages not updated since April 2022

2023-07-01 Thread Christopher Klooz via devel


Thanks for the quick reply ;)

I was only testing it in a VM as potential solution for a temporary 
weak-hardware use case - and I tend to prefer Qt-based solutions over GTK.


I have already the confined-user/SELinux issue and a project from Fedora 
Docs on my schedule, which are both waiting to start. I cannot put much 
more on my schedule at the moment ;)


However, if the SIG and the related maintainers cannot handle the LXQt 
packages at the moment either, it might be worth to discuss removing it 
from the promoted Spins list for now, doesn't it? Finally, the issue 
here is not just some average application but the desktop environment.


Maybe I am a little too conservative in this respect, but imho once we 
promote and provide it as a Spin, that goes along with some 
responsibility. Users may start to rely on it and use it for 
critical/private data and processes.


On 7/1/23 16:01, Neal Gompa wrote:

On Sat, Jul 1, 2023 at 8:38 AM Christopher Klooz via devel
 wrote:

Hi,

I was testing an instance of the LXQt Spin in a VM and saw that after
updating all packages, the LXQt packages are still with version 1.1.0,
which is from April 2022. Current is 1.3.0.

I read the LXQt team does not maintain itself, and 1.2.0 and 1.3.0 seem
to not contain critical security issues or so, but does someone keep
checking if something urgent comes up that requires action? (security or
compatibility issues, broken processes/automation at maintainers, ...)


Help is always desired and wanted. :)

Certainly if you're interested in LXQt and keeping it up to date,
helping out on that front would be greatly appreciated.




___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

LXQt Spin: packages not updated since April 2022

2023-07-01 Thread Christopher Klooz via devel


Hi,

I was testing an instance of the LXQt Spin in a VM and saw that after 
updating all packages, the LXQt packages are still with version 1.1.0, 
which is from April 2022. Current is 1.3.0.


I read the LXQt team does not maintain itself, and 1.2.0 and 1.3.0 seem 
to not contain critical security issues or so, but does someone keep 
checking if something urgent comes up that requires action? (security or 
compatibility issues, broken processes/automation at maintainers, ...)


Regards,
Chris
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Modules without modularity

2023-06-18 Thread Christopher

On Sat, Jun 17, 2023 at 9:12 PM Kevin Kofler via devel
 wrote:
>
> Petr Pisar wrote:
> > I understand the horror that you can have two packages which cannot be
> > installed at the same time. The same as you cannot start httpd and nginx
> > services at the same time. But now the conflict is visible on RPM level.
>
> You can actually, if you set them to different ports.
>
> But the issue here is that you can have 2 completely unrelated packages
> clashing over the version of some transitive dependency. Imagine not being
> able to install a KDE application on GNOME or vice-versa because of the KDE
> and GNOME stacks requiring a conflicting version of some "plumbing-layer"
> library. That is exactly the kind of scenario I and others want to avoid.
>
> > Of course. My proposal does not forbids it. If users of the
> > parallel-installable packages are fine with rewriting all their RPM
> > dependcies and file locations in their applications, then
> > parallel-installable packages are a perfect solution. It's simply a
> > different problem with a different solution.
>
> It is a different solution indeed, but I disagree about it solving a
> different problem. It solves the *same* problem in a different, better (from
> the end user's perspective – I know it is more work for the packager) way.

I question the "more work for the packager" viewpoint. I'm not sure
that's necessarily true, especially for casual packagers. From my
perspective, any Fedora guidelines that I can pull directly from
Fedora packaging documentation and merely have to modify a SPEC file,
is *far* less work for me than understanding a whole separate MBS
system and related tooling. Even if it's technically more "work" (time
consuming or tedious), the work is much easier when it's building on
existing knowledge. It's really about comprehensibility, and the
degree to which you can capitalize on existing knowledge, that
contributes to how much work is needed to use one solution vs.
another.

>
> 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: ACPI-related bug in 6.3.X? At least an issue in ucsi_acpi, affecting several systems

2023-06-15 Thread Christopher Klooz via devel

I assume there is a little confusion in 
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2511


-> the MR refers to the BZ#2212012-related ask.Fedora thread (f38, which 
can be mitigated by `|module_blacklist=ucsi_acpi|`) but it refers to the 
BZ#2213179 bug report (f37, which can be mitigated by removing the KVM 
switch but not by the blacklisting).


I assume I triggered the confusion because I mentioned both BZ# with 
their respective ask.Fedora threads in my original mail, but the 
BZ#2213179-KVM-issue only because of the two correlations (6.2.15 works, 
all later not; issues could both be explained by an acpi-related bug).


I already asked Justin to change the BZ# in Bodhi.

On 6/14/23 10:43, Hans de Goede wrote:

Hi Christopher,

On 6/13/23 23:26, Christopher Klooz via devel wrote:

In case you are already aware of the issue, feel free to ignore this mail. I 
just want to make aware that there could be multiple interrelated (bug) reports 
that might be considered in conjunction and not on their own, given that the 
amount of affected users is above average (I could imagine this is not limited 
to ask.Fedora).

As far as it concerns ask.Fedora: since 6.3 was introduced, we have many users 
in ask.Fedora with issues that seem to be ACPI related (more precisely, 
`ucsi_acpi`, but maybe not just this) and that makes it impossible to use 
kernels after 6.2.15 except with `module_blacklist=ucsi_acpi`.

I already asked the users to provide a bug report (this is how I became aware 
that the report template was broken ;), but I am not sure if the report(s) 
illustrate the number of users that have come up with the same issue. Since not 
all users with issues end up on ask.Fedora, we don't know the actual number of 
affected systems, but so many users with the same kernel issue is a seldom 
phenomenon.

So far, most users with 6.3.X ACPI-related issues are found in this topics:

https://discussion.fedoraproject.org/t/fedora-hangs-on-boot-after-upgrading-to-kernel-6-3-4/83605/

-> black screen after grub menu with stable kernels after 6.2.15
-> everything fine with 6.2.15
-> mitigation: module_blacklist=ucsi_acpi (several users confirmed this to 
mitigate the issue)

Links to the related bug reports are contained.


Thank you for reporting this and for the well written summary of the issue.

I believe that this is an issue which was already fixed recently and for which 
a patch is currently pending upstream:

https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-linus=c4a8bfabefed706bb9150867db528ceefd5cb5fe

I have submitted a merge-request to get this fix added to the Fedora kernels as 
a downstream patch for now:

https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2511

So that we can hopefully get this resolved for Fedora users ASAP.

Regards,

Hans

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

ACPI-related bug in 6.3.X? At least an issue in ucsi_acpi, affecting several systems

2023-06-13 Thread Christopher Klooz via devel

In case you are already aware of the issue, feel free to ignore this 
mail. I just want to make aware that there could be multiple 
interrelated (bug) reports that might be considered in conjunction and 
not on their own, given that the amount of affected users is above 
average (I could imagine this is not limited to ask.Fedora).


As far as it concerns ask.Fedora: since 6.3 was introduced, we have many 
users in ask.Fedora with issues that seem to be ACPI related (more 
precisely, `ucsi_acpi`, but maybe not just this) and that makes it 
impossible to use kernels after 6.2.15 except with 
`module_blacklist=ucsi_acpi`.


I already asked the users to provide a bug report (this is how I became 
aware that the report template was broken ;), but I am not sure if the 
report(s) illustrate the number of users that have come up with the same 
issue. Since not all users with issues end up on ask.Fedora, we don't 
know the actual number of affected systems, but so many users with the 
same kernel issue is a seldom phenomenon.


So far, most users with 6.3.X ACPI-related issues are found in this topics:

https://discussion.fedoraproject.org/t/fedora-hangs-on-boot-after-upgrading-to-kernel-6-3-4/83605/

-> black screen after grub menu with stable kernels after 6.2.15
-> everything fine with 6.2.15
-> mitigation: module_blacklist=ucsi_acpi (several users confirmed this 
to mitigate the issue)


Links to the related bug reports are contained.

The nvidia-driver issue that has accidentally merged in this topic is 
something different (the nvidia case is alredy solved anyway by an 
earlier kernel fix). The case in which already 6.2.15 was affected seems 
to be something different as well.


Except those nvidia-driver-users where a fixed kernel already solved the 
issue, in the cases where we identified it, affected users had `cat 
/proc/sys/kernel/tainted` = 0. Of course not all useres provided 
documentation so we cannot know for sure if that applies to all.


Additionally, it might be noted that we have further reports on 
ask.Fedora where users have issues that could have a link to ACPI, but 
not to `ucsi_acpi` in specific - so far it is only the correlation that 
6.2.15 works but everything later not, and that the respectively 
described issue could be explained by ACPI-related bugs (don't know 
yet). One F37 user consolidated their data in this bug report: 
https://bugzilla.redhat.com/show_bug.cgi?id=2213179 -> here the 
mitigation is removing the KVM switch in between system and monitor, 
although it works fine in 6.2.15. I think that's all reports with 
noteworthy data/documentation.


Not sure if we have further related reports elsewhere. Also, I check at 
the moment only those topics that are explicitly added to the #kernel 
category since I have little time, so maybe we have more reports about it.


Best,
Chris
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Modules without modularity

2023-06-13 Thread Christopher

On Tue, Jun 13, 2023 at 12:33 PM Petr Pisar  wrote:
>
> Hello,
>
> as it seems that module build infrastructure isn't getting any better, as
> modular YUM repositories are going to be deconfigured
> ,
> there is a time to look at different ways how to package alternative content.
>
> There are few aproaches, like compat packages, or full namespacing (Python).
> Yet modularity had some unique features, especially retaining nonmangled
> package names and other RPM dependencies.
>
> I spent some time thinking how to approximate the nice features with current
> state of RPM, Koji, and DNF and come up with this approach
> . The linked approach achieves
> it at the expense of dedicated build targets and an inability to introduce
> completely new modules (as opposite to new streams of existing modules) after
> releasing an installation media.
>
> Comments are welcome.
>
> -- Petr

(First the negative... don't worry, it's not all negative)
I wonder why we need this at all. I believe that modularity has failed
to gain a foothold in Fedora, just like scl before it, because Fedora
just doesn't need this. One of the best things about Fedora is the
dependency-convergence and curated nature of all the packaged
versions, so that everything works out of the box. The use cases for
alternative versions are edge cases that the vast majority of users do
not need or care about. And the ones that most users do care about
(making sure their application works) are usually satisfied with
compat packaging, when needed.

So much (over-?)engineering has gone into such niche use cases, and
Fedora is arguably no better off for all that effort. Nowadays, it's
so easy to spin up a VM or container using older versions of things,
if you need them, or you can use snaps or flatpaks, or
language-specific version management tools like mvn or rvm, for the
developer use cases. What is the real benefit to Fedora to continue to
push down the path of alternative, mutually-exclusive streams that
affect the entire system? My experience struggling with modularity as
a casual packager, and as a user, has left a bad taste in my mouth for
any similar attempts, and I'm highly skeptical of the need of such a
thing (and bracing for the impact when it all comes crashing down on
my favorite OS due to unintended consequences).

(Now the positive)
That said, I like the simplicity of your approach, using metapackages
and native RPM tooling to handle the situation. However niche the use
case is, having such a simple approach means that it's merely a matter
of documenting some guidelines for packagers to follow if they have
need of that situation. I still think that the need for that will be
rare, and wonder how many of these kinds of metapackages would
actually get created in Fedora. I suspect that it would be very few.
But the important bit is that if they do get created, they are
unlikely to affect me unless I want to use them. This is very
different from modularity, which seemed to have a downstream impact on
everybody, especially when you were forced to use modularity if your
dependencies were... which I think was enough to oust a lot of casual
packagers, because they had to understand a whole new dimension of
packaging guidelines and tooling. Your approach requires none of that.

The one downside to your approach, that I think was an early selling
point of modularity, is that yours kind of requires that the
alternative streams are built for every Fedora version. I think
modularity marketed itself as being able to have a module whose
version lifetimes were longer than OS release cycles (which could
reduce packager workload for streams that were slow-moving and didn't
change across Fedora releases). I don't know how much that actually
happened in practice, though, so I don't know if anybody will care
about that difference in your approach.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Kernel Bug Reports: Template broken?

2023-06-09 Thread Christopher Klooz



On 6/9/23 02:24, Kevin Fenzi wrote:

On Thu, Jun 08, 2023 at 09:21:38PM +0200, Christopher Klooz wrote:

Hi,

I saw that some users filed kernel bug reports, which lacked information.
Then I wanted to check the kernel bug report template and found out: there
is no longer a template.

So in the past, once the component "kernel" was chosen, the user was
provided with a template of the bug report, which informed them about what
they should provide (e.g., dmesg).

Is it intended that there is no longer a template or is it broken for some
reason?

It's likely broken by https://bugzilla.redhat.com/show_bug.cgi?id=1931587
(the new guided bug form for fedora).

Can you file a bug like
https://bugzilla.redhat.com/show_bug.cgi?id=2189110 to ask that it be
added back? Or I can if you prefer...


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

Thanks!
Chris



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

Kernel Bug Reports: Template broken?

2023-06-08 Thread Christopher Klooz


Hi,

I saw that some users filed kernel bug reports, which lacked 
information. Then I wanted to check the kernel bug report template and 
found out: there is no longer a template.


So in the past, once the component "kernel" was chosen, the user was 
provided with a template of the bug report, which informed them about 
what they should provide (e.g., dmesg).


Is it intended that there is no longer a template or is it broken for 
some reason?


Chris
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Salt is broken in Fedora 38 - asking a python-savvy provenpackager to help

2023-05-22 Thread Christopher

Hi,

Is anybody able to help fix salt-minion in F38? It's been broken
because of a newer version of python setuptools in F38. There's a
patch upstream, and the newer version also includes that patch. It
just needs to be incorporated into Fedora.

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

The maintainer does not seem to have responded in at least several
months on bugzilla. I'm not really a python person, and don't know
much about salt, and am not a provenpackager. But my $dayjob uses Salt
for some things, and if it doesn't start working again soon, I'm
afraid they'll revoke my permission to use Fedora at work. So, any
help to get this fixed would be greatly appreciated.

Thanks,
Christopher
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Error with libheif package

2023-04-22 Thread Christopher Klooz

Several users experience an issue with Fedora's `libheif` package, which 
can be easily reproduced:


See 
https://discussion.fedoraproject.org/t/unknown-update-error-with-libheif/81302/6


With regards to our default dnf repositories: our package has weak 
dependencies that are not satisfied by our default repos, but by 
rpmfusion once enabled. The conflict itself is in the related rpmfusion 
packages .


So once users have rpmfusion enabled, `dnf install/update libheif` ends 
up in a conflict because of `libheif-hevc` and `libheif-freeworld`.


Neil, I guess this information is relevant for you? Not sure if you are 
also involved with the two related rpmfusion packages (?).


Regards,

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

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

2023-04-21 Thread Christopher Klooz



On 4/21/23 17:27, Daniel Alley wrote:

If one uses OpenPGP and if people verify it

As you mention, that's a big "if"
Absolutely, and if the majority does not verify in the devel mailing 
list, it is clearly an indicator that this type of security is not 
relevant here ;) But finally, I am not sufficiently involved in all of 
our mailing lists to know.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: It’s time to transform the Fedora devel list into something new

2023-04-21 Thread Christopher Klooz



On 4/21/23 16:30, Aleksandra Fedorova wrote:

On 4/21/23 15:25, Christopher Klooz wrote:

Just a slight addition about "archaic email" and related comments:

Email and its capability for being used in conjunction with OpenPGP 
ensures two major institutions in kernel development and elsewhere: 
"Trusting the developers, not infrastructure" [1], and, assume "any 
part of the infrastructure can be compromised at any time" [1]. This 
avoids single points of failure, and complements the chain of trust.


I am not sure if Discourse is capable to be used in conjunction with 
OpenPGP if it reformats contents or if it removes attachments (maybe 
someone knows?). This leads to the possibility that discourse 
introduces a single point of failure (or, single point of 
vulnerability), which breaks the above institutions.


Having said that, as far as I follow our devel mailing list, I think 
the argument above is of minor relevance, because I think this 
mailing list is not used to forward code or to do reviews. Signatures 
seem to be not omnipresent at the moment anyway.


From security or impersonation point of view our current mailing list 
is actually the worst. Both Matrix and Discourse are at least tied to 
FAS account. And while it can be considered a single point of failure, 
it is at least the one which exists and is properly maintained by the 
project.
The FAS account is useless if one has access to the infra, or if the 
latter has vulnerabilities (which can be social and technical). 
Misconfigurations also occur in complex infra. That's the point of 
avoiding single points of failure. If one uses OpenPGP and if people 
verify it, it is not relevant if the infra itself is the "worst" or not, 
because no one needs to trust it anyway (that's the point in the kernel 
mailing lists). By default, without ensuring integrity, every 
email-based mailing list that is used in Linux realms (and at all) falls 
in the "worst" category because of the concept/architecture of email.


Again, this does not mean that discourse is not suitable for us. Given 
what I see on the mailing lists, our mailing list contents seem to be 
not relevant for integrity, and mostly not signed at all.


I just read some comments where I had the perception that they are 
partly assuming things to be simpler than they are. There are reasons 
for traditional email mailing lists in some circumstances, they are not 
"generally obsolete", but this does not mean that this applies to our 
mailing lists.


Given what I see and where I am present in the mailing lists, I would be 
+1 for discourse. But we still have to consider and put forward all points.


So I think we are on the same page, I just added a point that has to be 
considered in advance: do we have >=1 mailing lists that have a need for 
independent "security of integrity"? I guess the answer is no, we do not 
have >=1. But I do not know all of our mailing lists and for what they 
are used.


We had the issue with impersonation over e-mail before, and that was 
not nice.


However, I just wanted to remind that the issue is a little more 
complex than just assuming "email is old and has to be replaced by 
modern": there is another consideration, too. And we have to be aware 
that if discourse does not support OpenPGP signatures practically, we 
loose the possibility to ensure "security of integrity" in the 
mailing list in cases WHEN it is necessary - IF there are such cases 
(which I cannot determine).


I think we really try hard to not oversimplify the conversation to the 
point of "old" vs "new", or "us" vs "them" approach, though many of 
the replies in this thread are pulling us into that direction.


Matthew's mail in my opinion does a good job to highlight that there 
is no single "we want a new shiny thing for newbies" driver behind the 
switch. There are multiple reasons for it. And making discussions more 
secure and better maintained is on that list too.


And like, hey, e-mail is a still a thing. Use it where you need it, 
and where it fits. There is no fight against the technology.


But for this particular purpose within this particular environment the 
mailing list just doesn't work(*), and we see it.


(*) Works = provides shared space where old and new Fedora 
contributors can discuss changes and other project-related topics in a 
collaborative way to advance the project.


This is the problem which we must solve. And it won't go away on its 
own if just wait for it.


Again, the goal is not to fight against Fedora contributors using the 
e-mail technology. The goal is to find a solution.


And if the requirement for that solution is to improve the Discourse 
mail interface, can we at least try to look into it with open mind and 
actually list what needs to be done to make it work.


We are a group of FOSS developers using

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

2023-04-21 Thread Christopher Klooz


Just a slight addition about "archaic email" and related comments:

Email and its capability for being used in conjunction with OpenPGP 
ensures two major institutions in kernel development and elsewhere: 
"Trusting the developers, not infrastructure" [1], and, assume "any part 
of the infrastructure can be compromised at any time" [1]. This avoids 
single points of failure, and complements the chain of trust.


I am not sure if Discourse is capable to be used in conjunction with 
OpenPGP if it reformats contents or if it removes attachments (maybe 
someone knows?). This leads to the possibility that discourse introduces 
a single point of failure (or, single point of vulnerability), which 
breaks the above institutions.


Having said that, as far as I follow our devel mailing list, I think the 
argument above is of minor relevance, because I think this mailing list 
is not used to forward code or to do reviews. Signatures seem to be not 
omnipresent at the moment anyway.


However, I just wanted to remind that the issue is a little more complex 
than just assuming "email is old and has to be replaced by modern": 
there is another consideration, too. And we have to be aware that if 
discourse does not support OpenPGP signatures practically, we loose the 
possibility to ensure "security of integrity" in the mailing list in 
cases WHEN it is necessary - IF there are such cases (which I cannot 
determine).


Just some thoughts :)

[1] https://www.kernel.org/doc/html/latest/process/maintainer-pgp-guide.html

Chris

On 4/21/23 11:42, Aleksandra Fedorova wrote:

On 4/21/23 02:57, Solomon Peachy via devel wrote:

On Thu, Apr 20, 2023 at 07:21:54PM -0400, Simo Sorce wrote:

Hi Matthew, you say: "We're missing people", and I think, "who?".
And who are you going to miss if you move to discourse?


Again and again I have seen this "we're missing people" sentiment be
used to justify scrapping "old" workflows, and *not once* has it ever
resulted in "more people" coming out of the woodwork that would have
happily contributed in the past, but were turned off/away by the need to
use archaic email.


Funny, how from where I am sitting I can not really remember any time 
we managed to scrape the old workflow at least once. So I wouldn't be 
able to measure the effectiveness of such an imaginary thing. I can 
only see how we are unable to do changes and therefore we are always 
adding things on top of old ones, which of course doesn't make 
anything easier neither for those who want to change, nor for those 
who don't.


That's a slight exaggeration of course, but so is your statement. 
People come to Fedora via many ways. But I doubt any of it starts with 
e-mail nowadays. And the fact that you don't see newcomers _here_ 
actually proves the point, isn't it?



(FFS, If we're going to follow this to its logical conclusion, we should
  just scrap all of this email/discourse/whatever and just move
  everything to github, or even facebook, as that's clearly where the
  most numbers of people are.  "but no, our custom tooling makes things
  better for us" is the inevitable pushback, which arguably applies just
  as much to email-based flows!)


The mailing list make messages land in my client, on which I am very
efficient, therefore I can check all messages once a day, and respond
if I find a worthy topic.


...and the very nature of Discourse or various other Forums pretty much
make this sort of workflow impossible; that is to say you're all but
forced to manually poll every site you care about in a way that all but
makes automation impossible.


Discourse

1) sends email in a multipart format which has html and plain 
text(kind of markdown);
2) adds headers which allow you to filter the messages by topic or 
category on the client-side;
2) allows you to configure notifications for mentions per category or 
per tag;
3) allows to configure custom searches on the server side, and will 
notifies you for it.


Here is the example of the mail headers:


Message-ID: 
In-Reply-To: 
References: 
 
 
List-Unsubscribe: <...>
X-Discourse-Post-Id: 215862
X-Discourse-Topic-Id: 81258
X-Discourse-Category: Team Workflows/Fedora Magazine
X-Auto-Response-Suppress: All
Auto-Submitted: auto-generated
Precedence: list
List-ID: Fedora Discussion | Team Workflows Fedora Magazine
 
List-Archive: 
https://discussion.fedoraproject.org/t/article-proposal-using-btrfs-to-upgrade-fedora/81258

Feedback-ID: fedoraproject:user_posted:discoursemail



It is not perfect, and it requires some effort. But I don't see why it 
is impossible.



In other words, it's locally optimal for any given site, but is utterly
incapable of scaling if you care about more than a small handful of 
sites.


Calling myself semi-active here would be quite generous, but I can
uneqvocibly state that if I have to manually poll a discourse site or
whatever, that will be the end of my participating in

[EPEL-devel] Packages for PHP 8.1

2023-02-21 Thread Joseph Christopher Sible

Hello,

I have a RHEL 9 system running PHP 8.1 from the Red Hat AppStream module. I 
tried to install php-sodium and php-pecl-imagick from EPEL 9 on it, but DNF 
gave an error that basically said those packages only work with PHP 8.0. Would 
it be possible to provide versions of those packages that are compatible with 
PHP 8.1 too?

Thanks,

Joseph C. Sible
___
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: asciiDoc: Package outdated; unresponsive maintainer?

2023-02-18 Thread Christopher Klooz

Thanks for the information. I filed a ticket, so everyone should get an 
email, including Fab by his private mail address: 
https://bugzilla.redhat.com/show_bug.cgi?id=2171184


On 2/18/23 14:06, Ben Beasley wrote:

Fabian Affolter has been consistently active in Fedora. At the same time, he 
maintains a huge number of packages that he does not seem to have time to keep 
up to date. My experience is that he usually does not—but occasionally 
does—respond to efforts to contact him, including Bugzilla, PR’s, and direct 
email. You might also try the email address m...@fabian-affolter.ch.

Please see also this nonresponsive maintainer ticket from a few months ago: 
https://pagure.io/fesco/issue/2872

You may have better luck with one of the other maintainers of the asciidoc 
package.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

asciiDoc: Package outdated; unresponsive maintainer?

2023-02-18 Thread Christopher Klooz


Hi all,

Does anyone know about the maintainer "Fab"?

I have tried to contact him through 
asciidoc-maintain...@fedoraproject.org on 29th January and through 
f...@fedoraproject.org on 11th February, but did not received an answer 
from either.


asciiDoc has not been updated for two years with 10 releases since (we 
have 9.1, current is 10.2): See the attached email below.


I have not yet opened a ticket against asciiDoc, I thought maybe someone 
here knows about him? It's nothing time critical obviously.


 Forwarded Message 
Hi Fab,

I saw in src.fp.org that you are the asciiDoc maintainer.

It seems asciiDoc has not been updated since Feb 2021. There have been 
10 new releases since then, although there is nothing urgent contained I 
think.


I wrote an email with details to asciidoc-maintain...@fedoraproject.org 
but have not received an answer (see the attached email below).


Although there have been several bug fixes and some new features since 
then, a rough skim over the release notes on GitHub [1] does not 
indicate security-critical issues at the moment, and I have no stability 
issues either on F37. Nevertheless, I think it makes sense to take a 
look at the package in the medium term?


[1] https://github.com/asciidoc-py/asciidoc-py/releases

All the best & stay safe.
Regards,
Chris
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Obsolete version of "x11docker" in koji/bodhi; no updates for two years (orphaned?)

2023-01-27 Thread Christopher Klooz


No worries. Thanks!

On 1/27/23 19:41, Davide Cavalca wrote:

On 2023-01-27 10:34, Christopher Klooz wrote:

Hi,

I just saw that a package (x11docker) seems to be orphaned: we ship a
very old release (many releases since June 2021), and when reviewing
the release notes of subsequent releases on github of that package, I
think this old release (from June 2021) should no longer be deployed:
see https://github.com/mviereck/x11docker/releases


This is my package. It's not orphaned, I just wasn't aware of new 
releases because this isn't wired properly in Anitya (fixing that now).



I assume the user "releng" indicates that there is currently no active
maintainer, doesn't it? (Since "release engineering" took over the
builds, no new release has been added)

https://koji.fedoraproject.org/koji/packageinfo?packageID=33907
https://bodhi.fedoraproject.org/updates/?packages=x11docker


Nope, that just means that a bunch of mass rebuilds happened since the 
last manual build.



Maybe it makes sense to remove that package from the repos? Just to
avoid people installing and using it with the assumption that this
package still receives updates  (I'm not sure if users could
accidentally interpret the F37 in "6.9.0-5.fc37" of dnf's output as
indication that this is an up to date package).


I'll take a look and see if we can get this updated.

Cheers
Davide

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Obsolete version of "x11docker" in koji/bodhi; no updates for two years (orphaned?)

2023-01-27 Thread Christopher Klooz


Hi,

I just saw that a package (x11docker) seems to be orphaned: we ship a 
very old release (many releases since June 2021), and when reviewing the 
release notes of subsequent releases on github of that package, I think 
this old release (from June 2021) should no longer be deployed: see 
https://github.com/mviereck/x11docker/releases


I assume the user "releng" indicates that there is currently no active 
maintainer, doesn't it? (Since "release engineering" took over the 
builds, no new release has been added)


https://koji.fedoraproject.org/koji/packageinfo?packageID=33907
https://bodhi.fedoraproject.org/updates/?packages=x11docker

Maybe it makes sense to remove that package from the repos? Just to 
avoid people installing and using it with the assumption that this 
package still receives updates  (I'm not sure if users could 
accidentally interpret the F37 in "6.9.0-5.fc37" of dnf's output as 
indication that this is an up to date package).


Regards,
Chris
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Fedoras GnuPG default option is deprecated

2023-01-05 Thread Christopher Klooz

Indeed, makes sense. It is not reported atm in bugzilla, but I just had 
a few minutes time. I filed it against gnupg2 and referred to this 
mailing list topic and to the upstream link Todd provided: 
https://bugzilla.redhat.com/show_bug.cgi?id=2158627


On 05/01/2023 04:05, Peter Robinson wrote:

On Wed, Jan 4, 2023 at 3:37 PM Christopher Klooz  wrote:

A fresh installation of Fedora 37 has by default the "--supervised"
option active in its gpg-agent systemd file
(/usr/lib/systemd/user/gpg-agent.service).

According to GnuPG Docs [1], this option is deprecated. Once gpg-agent
is invoked, the log of "systemctl --user status gpg-agent.service"
confirms that with: "gpg-agent[2022]: WARNING: "--supervised" is a
deprecated option"

Is this intended?

Off the cuff I do not see an immediate security issue, but I guess it
makes sense to get over deprecated options.

I would check bug reports [1] and file a bug if there's not one
already so it can be tracked, the maintainer may not follow this list
closely.

[1] 
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=gnupg2=Fedora=Fedora%20EPEL
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Fedoras GnuPG default option is deprecated

2023-01-04 Thread Christopher Klooz

A fresh installation of Fedora 37 has by default the "--supervised" 
option active in its gpg-agent systemd file 
(/usr/lib/systemd/user/gpg-agent.service).


According to GnuPG Docs [1], this option is deprecated. Once gpg-agent 
is invoked, the log of "systemctl --user status gpg-agent.service" 
confirms that with: "gpg-agent[2022]: WARNING: "--supervised" is a 
deprecated option"


Is this intended?

Off the cuff I do not see an immediate security issue, but I guess it 
makes sense to get over deprecated options.


Regards,
Chris

[1] https://www.gnupg.org/documentation/manuals/gnupg/Agent-Commands.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: Issue with configuration of nested virtualization

2022-12-28 Thread Christopher Klooz

I have just checked current Docs of libvirt (which I consider most
representative/relevant) about host-passthrough and host-model (and a
related SuSE page for comparison with RHEL concerning host-passthrough):
host-passthrough/-model are still different and both are what they used
to be.

Concerning host-passthrough etc. see:
https://libvirt.org/formatdomain.html
https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-libvirt-config-virsh.html
-> concerning host-passthrough, both can be transferred to your Quick
Docs article about nested virt -> the considerations about
host-passthrough/-model are the same.
Be aware that host-passsthrough is not a real hardware passthrough like
pci-passthrough. It only imitates the exact host CPU. Therefore, it is a
passthrough of "hardware properties/behavior", not of hardware itself.
You could also argue that host-passthrough = "imitation". This has
positive performance outcomes: better CPU performance for the guest, and
less emulation overhead for the host. The general performance advantages
are the reason why I disagree with the second sentence of the current
Note box (see my last mail).
Concerning the migration issue: the issue applies mostly to environments
that contain extraordinary CPUs, and are critical, complex and/or
automated and need to provide constant predictable hardware behavior
(which therefore, has to be officially supported and explicitly tested).
Fedora is not intended for critical infra anyway. Additionally, the
issue is increasingly likely to apply to those who further customize the
host-passthrough in the configuration file.
Maybe you can add a Note box that makes somehow aware of the following:
generally, you can say with host-passthrough, the migration issue for
the guest is mostly equal to the migration issue of the host: the CPU
has changed, so everything that runs on top of that CPU has to adjust
correspondingly. Mainstream guests possibly do not even care and are
able to tailor automatically at boot (but I guess a paused VM should not
be migrated while at pause, including snapshots of running systems :).
ADDITION: depending on the host-passthrough configuration, it might be
possible that it becomes necessary to adjust the xml config file when
the host CPU changes (might apply mostly to those who customized the
configuration file). Adjustments, if necessary, should be easy and are
not "nested virtualization" specific.
The point of libvirt's bug warning is: host-passthrough imitates exactly
what the host CPU does/contains, not what has been explicitly
tested/integrated in the software. This means that the user can enter
formally untested grounds. You can make the user aware that
host-passthrough-based "testing" of VM that has been conducted on one
CPU cannot be automatically transferred to another CPU. On mainstream
hardware, I have never experienced or seen an issue since libvirt/kvm
have reached "maturity", but formally, the point might be noted for
cases where the hardware is not fully known by the virt software. But be
careful to not "threaten" users, since in most cases, host-passthrough
should work properly... Since the "audience level" might be comparable,
feel free to let yourself inspire by the RHEL and SuSE Docs when it
comes to what to mention and what not.
My arguments about host-passthrough/-model are valid. But I cannot help
with modprobe <-> nested virtualization: for that, I suggest to search
for topics on ask.fedora and if necessary, open a topic there. We had
nested virtualization topics in the past, so maybe someone there can
help you with that.

Cheers,
Chris

On 28/12/2022 09:34, Peter Boy wrote:

Hi Chris,

Am 27.12.2022 um 23:01 schrieb Christopher Klooz:
...
The Red Hat Docs you refer to differ to the Quick Docs page: see 1. II. of the
procedures of both Intel and AMD at the RHEL link (as you indicated, it seems
that RHEL 9 has not yet anything online about the topic, at least not on the
publicly available pages).

Yes, the RHEL documentation is more specific. However, there remains the
inconsistency regarding the information in the /etc/modprobe.d/kvm.conf file in
Fedora (don’t know if it exist in RHEL, too). Is this a remnant of old ways of
configuration or some kind of fallback? It would be helpful to get some
information about this.

Re: Issue with configuration of nested virtualization

2022-12-27 Thread Christopher Klooz

Hi Peter,

I have not much experience with nested virtualization in particular. But
although I am quite sure that it will not fail without host-passthrough,
I cannot imagine it to be sufficiently efficient without making use of
host-passthrough in production (and also not effective in many use
cases). So concerning enabling the host-passthrough, I assume that makes
sense.

The Red Hat Docs you refer to differ to the Quick Docs page: see 1. II.
of the procedures of both Intel and AMD at the RHEL link (as you
indicated, it seems that RHEL 9 has not yet anything online about the
topic, at least not on the publicly available pages).

The RHEL8 Docs page makes use only of "host-passthrough", whereas the
Quick Docs article seems to assume that "host-passthrough" and
"host-model" are equal and thus, the user can use any of the two without
a difference. At least as I was working with that the last time (maybe
something has changed? * ), these were two different things (host
passthrough <-> host model), and for performance reasons, I suggest to
stick with "host-passthrough" and not "host-model" in the nested use
case, except there is clear indication towards the other (see the
openstack link below for an example). At least, the quick docs article
should make clear the difference if it also notes "host-model". Or
alternatively, duplicate the RHEL8 Docs page approach and refer only to
"host-passthrough", which makes most sense for that use case imho.

Additionally, I disagree a bit with the "Note" box in
https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-in-kvm/#proc_configuring-nested-virtualization-in-virt-manager

" Using host-passthrough is not recommended for general usage. It should
only be used for nested virtualization purposes. "

I am not sure if nested virtualization is the only reason to enable
host-passthrough. So at least the second sentence ("It should only be
used for nested virtualization purposes") should be removed imho. I
think implicit assumptions should be avoided at all.

Concerning the difference of host-passthrough and host-model, the
following link contains some information about the two that corresponds
to what I know: https://wiki.openstack.org/wiki/LibvirtXMLCPUModel (just
search on that page for "host-passthrough" and "host-model"). If you
search on the Internet for further information, be aware that the terms
"host-passthrough" and "pci-passthrough" are not synonymous (you will
maybe get many pages about both when querying a search machine about one
of them).

To avoid misunderstandings: I have not reviewed/tested the remaining
article. Maybe someone else has the capabilities for that.

* I cannot exclude that there have been some developments in this area
since I was using that the last time, but given the age of the Quick
Docs article, I expect the "host-passthrough = host-model" assumption
was wrong at the time of writing (being no indication for what is
currently correct), and therefore, unless someone knows it better, I
guess it makes sense to assume that there is still a difference between
the two...

Hope that helps a bit.

Regards & stay safe,

Chris

On 27/12/2022 12:59, Peter Boy wrote:

In order to use nested virtualization, Fedora Quick Docs[1] advises to activate
that feature in the host kernel using modprobe and editing the file
/etc/modprobe.d/kvm.conf. The comment in this file provides the same
information. Additionally, you are to configure the processor of the VM hosting
a nested VM as passthrough. The RHEL 8 documentation [2] provides the same
information as various articles on other Web pages. In RHEL 9 documentation I
couldn’t find anything about this. Additionally, you are to configure the
processor of the VM hosting a nested VM as passthrough.

According to my findings these informations seem to be obsolete or in need of
supplementation. At least everything works fine without any additional
configuration at all (at least if the host processor as well as the processor
configured in the VM support virtualization).

The Fedora docs team is in the process to check and update Fedora documentation.

It would be really helpful if someone with more technical knowledge about that
matter than me would provide me with more detailed information und maybe links
to current information. Even better if someone familiar with the matter would
be willing to review an updated article.

--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
p...@fedoraproject.org

Timezone: CET (UTC+1) / CEST (UTC+2)

Fedora Server Edition Working Group member
Fedora docs team contributor and board member
Java developer and enthusiast

[1]
https://docs.fedoraproject.org/en-US/quick-docs/using-nested-virtualization-in-kvm/
[2]

Re: Karma for OpenSSL needed

2022-11-01 Thread Christopher Klooz


Just tested and added karma to f36 and f37. Thanks!

On 01/11/2022 18:22, Dmitry Belyavskiy wrote:

Dear colleagues,

I've just pushed the updates for OpenSSL fixing 2 CVEs evaluated as 
HIGH. Could you please check the freshly pushed builds to get 
necessary karma ASAP?


Many thanks!

--
Dmitry Belyavskiy

___
devel mailing list --devel@lists.fedoraproject.org
To unsubscribe send an email todevel-le...@lists.fedoraproject.org
Fedora Code of 
Conduct:https://docs.fedoraproject.org/en-US/project/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: Grub menu with 3 kernels by default



On 05/10/2022 20:28, Hans de Goede wrote:

Hi,

On 10/5/22 19:59, Christopher Klooz wrote:

On 05/10/2022 18:39, Christopher Klooz wrote:

On 05/10/2022 17:33, Chris Murphy wrote:

On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:


However, on ask.fp, a user mentioned that the grub menu is no longer
enabled by default on single boot systems so that changing the kernel is
no longer easily possible, and put forward
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
this argument. Yet, the article indicates that the argument is not fully
correct and even with single boot installations, SHIFT can be used to
get into the grub menu.

I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, because 
it's reserved by UEFI firmware for one of its menus. And SHIFT has never 
worked. Maybe Esc or TAB?

Holding left shift is the easiest method, but with firmware being
firmware does not work on all systems.

What does always work is ESC or F8, Fedora's grub supports both to
show the menu. On some systems one of those key get intercepted by
the firmware which is why there are 2 choices.


Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.



Me, too. Especially as it makes support more problematic for unexperiened users. It is 
easy to say that people should push another kernel when they see the grub menu. They see 
text, and I can tell them which text to choose. But with unexperiened users, telling when 
to push tab/esc/shift/F8 can already need to start an elaboration of what 
"boot" means and when this happens and so on. Such elaborations are already 
annoying for them (and for the supporters).

The menu automatically unhides after a failed boot. Just blindly
doing ctrl + alt + f4 followed by ctrl + alt + delete; or just
power-cycling the machine counts as a failed boot.
Many problems that can occur do not cause a failed boot. This starts 
with the current issue in 5.19.12. Another widespread issue is that 
users have problems with a piece of hardware (e.g., bluetooth 
controller), or with modules causing unintended behavior with one kernel 
(freeze, slow, something like wifi or bluetooth does not work, other 
acpi issues, and so on). All that does not necessarily cause failed 
boots, but is widespread among our "user base" at ask.fp especially 
because Fedora is used on much different hardware, and some needs 
additionally external modules.


We have spend a lot of time on creating a smooth boot experience
without any menus filled with "techno babble" which scare
novice users. Lets avoid regressing on this.


I am not sure if the outcome is even more scary for users, especially 
unexperienced users. Finding out which key to use seems to be not smooth 
even for experienced people in the devel mailing list. Also, I am not 
sure if this perception of unexperienced users who want to get rid of 
"seeing any type of text" reflects our less-techy user base. My 
perception at ask.fp or from conferences is different. But I already 
elaborated that in my previous mails.




If anything what we need is to:

1. Detect we are running not the latest kernel
2. Pop up a dialog that 1. is true and ask the user if there
were issues with the latest kernel and if yes if they want
to pin the currently running kernel for say the next month ?

Regards,

Hans


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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: Grub menu with 3 kernels by default

On 05/10/2022 18:39, Christopher Klooz wrote:

On 05/10/2022 17:33, Chris Murphy wrote:

On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:

However, on ask.fp, a user mentioned that the grub menu is no longer
enabled by default on single boot systems so that changing the
kernel is

no longer easily possible, and put forward
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
this argument. Yet, the article indicates that the argument is not
fully

correct and even with single boot installations, SHIFT can be used to
get into the grub menu.
I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found,
because it's reserved by UEFI firmware for one of its menus. And
SHIFT has never worked. Maybe Esc or TAB?

Given this inconsistency, I have a mixed opinion of the hidden GRUB
menu.

Me, too. Especially as it makes support more problematic for
unexperiened users. It is easy to say that people should push another
kernel when they see the grub menu. They see text, and I can tell them
which text to choose. But with unexperiened users, telling when to
push tab/esc/shift/F8 can already need to start an elaboration of what
"boot" means and when this happens and so on. Such elaborations are
already annoying for them (and for the supporters).

I know that many unexperienced users don't like if they have to work
in text mode, or if they have to work with these texts. But the
appearance of a grub menu that automatically makes the choice for them
is something I have never heard a complaint about. Also, people don't
like if they are urged to seek help (which they have to because
unexperiened users will often not formulate search queries that makes
them end up on helpful/related documentation). If they see the menu,
many find out themselves what this is and for what they can use it,
supporting their independence (others simply ignore it).

Maybe it makes sense to revert the hiding of the menu?

In any case, the information we provide should be updated to be
consistent. F8/SHIFT/ESC/TAB? I cannot verify which is currently the
correct button as I do not experience that behavior. However, it is
interesting that I have this behavior not on my single-boot systems.
Maybe further inconsistency can get introduced by firmware (another
complication that could make it more complicated for users - and
supporters obviously as well).
I cannot verify Jeff's comment (this one:
https://ask.fedoraproject.org/t/does-the-grub-menu-appear-by-default-on-single-boot-workstation-installations/27270/8
), but he says that the hiding of the grub menu was already reverted for
new installations in one of the recent releases.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/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: Grub menu with 3 kernels by default


On 05/10/2022 17:33, Chris Murphy wrote:


On Wed, Oct 5, 2022, at 11:16 AM, Christopher Klooz wrote:


However, on ask.fp, a user mentioned that the grub menu is no longer
enabled by default on single boot systems so that changing the kernel is
no longer easily possible, and put forward
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu as evidence for
this argument. Yet, the article indicates that the argument is not fully
correct and even with single boot installations, SHIFT can be used to
get into the grub menu.
I think it's F8 or SHIFT. F8 doesn't work on many laptops I've found, 
because it's reserved by UEFI firmware for one of its menus. And SHIFT 
has never worked. Maybe Esc or TAB?


Given this inconsistency, I have a mixed opinion of the hidden GRUB menu.


Me, too. Especially as it makes support more problematic for 
unexperiened users. It is easy to say that people should push another 
kernel when they see the grub menu. They see text, and I can tell them 
which text to choose. But with unexperiened users, telling when to push 
tab/esc/shift/F8 can already need to start an elaboration of what "boot" 
means and when this happens and so on. Such elaborations are already 
annoying for them (and for the supporters).


I know that many unexperienced users don't like if they have to work in 
text mode, or if they have to work with these texts. But the appearance 
of a grub menu that automatically makes the choice for them is something 
I have never heard a complaint about. Also, people don't like if they 
are urged to seek help (which they have to because unexperiened users 
will often not formulate search queries that makes them end up on 
helpful/related documentation). If they see the menu, many find out 
themselves what this is and for what they can use it, supporting their 
independence (others simply ignore it).


Maybe it makes sense to revert the hiding of the menu?

In any case, the information we provide should be updated to be 
consistent. F8/SHIFT/ESC/TAB? I cannot verify which is currently the 
correct button as I do not experience that behavior. However, it is 
interesting that I have this behavior not on my single-boot systems. 
Maybe further inconsistency can get introduced by firmware (another 
complication that could make it more complicated for users - and 
supporters obviously as well).

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/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

Grub menu with 3 kernels by default