from:"Christopher Klooz"



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

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

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