[EPEL-devel] Fedora EPEL 9 updates-testing report

2023-12-24 Thread updates 
The following Fedora EPEL 9 Security updates need testing:
 Age  URL
   5  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b19336b76b   
tor-0.4.8.10-1.el9
   3  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-7ff32fc746   
podman-tui-0.15.0-2.el9
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b698d8c031   
proftpd-1.3.8b-1.el9
   2  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b300e89045   
chromium-120.0.6099.129-1.el9
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-75bf3d635e   
xerces-c-3.2.5-1.el9


The following builds have been pushed to Fedora EPEL 9 updates-testing

paho-c-1.3.13-2.el9
python-django-appconf-1.0.6-1.el9
stduuid-1.2.3-1.el9

Details about builds:



 paho-c-1.3.13-2.el9 (FEDORA-EPEL-2023-15fe31c7f5)
 MQTT C Client

Update Information:

update

ChangeLog:

* Sun Dec 24 2023 topazus  - 1.3.13-2
- fix file format style
* Tue Dec  5 2023 topazus  - 1.3.13-1
- update to 1.3.13
* Thu Jul 20 2023 Fedora Release Engineering  - 
1.3.9-7
- Rebuilt for https://fedoraproject.org/wiki/Fedora_39_Mass_Rebuild
* Thu Jan 19 2023 Fedora Release Engineering  - 
1.3.9-6
- Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild
* Fri Jul 22 2022 Fedora Release Engineering  - 
1.3.9-5
- Rebuilt for https://fedoraproject.org/wiki/Fedora_37_Mass_Rebuild
* Thu Jan 20 2022 Fedora Release Engineering  - 
1.3.9-4
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild

References:

  [ 1 ] Bug #2203839 - Please release it for EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2203839




 python-django-appconf-1.0.6-1.el9 (FEDORA-EPEL-2023-60bdcd6531)
 An app to handle configuration defaults of packaged Django apps gracefully

Update Information:

1.0.6 (2023-11-20) --  * Updated declared support and testing
for Django 5.0 and 4.2, and Python 3.12.  1.0.5 (2021-09-24) --
* Adds testing against latest non-EOL Python and Django versions and updates
package metadata accordingly.  1.0.4 (2020-04-01) --  * Run
tests for Django 2.2 and 3.0 and Python 3.5, 3.6, 3.7 and 3.8  * Add template
and middleware settings in test_settings (required for Django 2.2)

ChangeLog:

* Sun Dec 24 2023 Michel Lind  - 1.0.6-1
- Update to 1.0.6
- Modernize for new Python Packaging Guidelines
- Use SPDX license identifier

References:

  [ 1 ] Bug #1684893 - python-django-appconf-1.0.6 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1684893




 stduuid-1.2.3-1.el9 (FEDORA-EPEL-2023-efa31245d1)
 A C++17 cross-platform implementation for UUIDs

Update Information:

update

ChangeLog:

* Sun Dec 24 2023 topazus  - 1.2.3-1
- initial import; rhbz#2255198


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

Re: rpmbuild core dumps

2023-12-24 Thread Sam Varshavchik 

Stephen Smoogen writes:

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


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


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

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





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

Re: rpmbuild core dumps

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

Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren


On Sun, Dec 24, 2023 at 14:27 Sam Varshavchik  wrote:

> It seems that rpmbuild dumps core at the end of the build process, every
> once in a while. Typical:
>
> Wrote:
> /__w/courier-libs/courier-libs/courier-authlib/rpm/RPMS/x86_64/courier-authlib-userdb-debuginfo-0.72.0.20231223-101.fc39.x86_64.rpm
> Wrote:
> /__w/courier-libs/courier-libs/courier-authlib/rpm/RPMS/x86_64/courier-authlib-devel-0.72.0.20231223-101.fc39.x86_64.rpm
> double free or corruption (fasttop)
> make[1]: *** [Makefile:2447: dorpm] Aborted (core dumped)
> make[1]: Leaving directory '/__w/courier-libs/courier-libs/courier-authlib'
> make: *** [Makefile:2439: rpm-build] Error 2
>
> Just trying again, with the same build, typically succeeds. In my
> estimate
> it dumps core about 5% of the time, randomly.
>
> I can rule out a hardware issue on my side, because this just happened in
> a
> github workflow container:
>
>
> https://github.com/svarshavchik/courier-libs/actions/runs/7315972215/job/19930137170
>
> You'll probably need to be signed into github see the log, but that's
> basically it.
>
> I can't find anything relevant in Bugzilla, is anyone else seeing this,
> too?
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> 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 Sam Varshavchik 

Kevin Kofler via devel writes:


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

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


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


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


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



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

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


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




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

rpmbuild core dumps

2023-12-24 Thread Sam Varshavchik 
It seems that rpmbuild dumps core at the end of the build process, every  
once in a while. Typical:


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

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


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


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

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


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



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

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

2023-12-24 Thread Kevin Kofler via devel 
Leon Fauster via devel wrote:
> 
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/libnm-core-impl/nm-setting-wireless.c#L1598

So NM supports both, which leaves the question: Is the proposal to default 
to "stable-ssid" (or to "stable" with the stable-ID set to the SSID), or to 
plain "stable"?

As explained in my other mail, "stable-ssid" is basically useless, whereas 
plain "stable" has the potential to break things (as Robert Nichols 
explained).

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

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

2023-12-24 Thread Kevin Kofler via devel 
Sam Varshavchik wrote:
> The ostensible reason for this is that you cannot be tracked by your fixed
> MAC across different APs.

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

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

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

For the randomization implementation, there are actually 2 possibilities to 
get a stable MAC per AP: hash the text SSID, or hash the BSSID. Which does 
NetworkManager use? The text SSID will be the same for all APs belonging to 
the same large network, so hashing with that will not prevent such large 
networks from tracking you, down to knowing pretty accurately where you are 
geographically (because they know which of their APs you connected to). 
Hashing the BSSID instead prevents that (unless the operator manages to 
spoof the same BSSID everywhere, which I guess you cannot really prevent on 
the client side either, though it will fail them if the AP's ranges 
overlap), but it also means that network-wide MAC address filtering will no 
longer work.

Blocking tracking also blocks filtering, and the other way round.

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

[Bug 2251788] perl-Net-DNS-1.42 is available

2023-12-24 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2251788



--- Comment #5 from Upstream Release Monitoring 
 ---
the-new-hotness/release-monitoring.org's scratch build of
perl-Net-DNS-1.42-1.fc38.src.rpm for rawhide completed
http://koji.fedoraproject.org/koji/taskinfo?taskID=110789627


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251788%23c5
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2251788] perl-Net-DNS-1.42 is available

2023-12-24 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2251788



--- Comment #4 from Upstream Release Monitoring 
 ---
Created attachment 2005680
  --> https://bugzilla.redhat.com/attachment.cgi?id=2005680=edit
Update to 1.42 (#2251788)


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251788%23c4
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Bug 2251788] perl-Net-DNS-1.42 is available

2023-12-24 Thread bugzilla 
https://bugzilla.redhat.com/show_bug.cgi?id=2251788

Upstream Release Monitoring  
changed:

   What|Removed |Added

Summary|perl-Net-DNS-1.41 is|perl-Net-DNS-1.42 is
   |available   |available



--- Comment #3 from Upstream Release Monitoring 
 ---
Releases retrieved: 1.42
Upstream release that is considered latest: 1.42
Current version/release in rawhide: 1.40-1.fc40
URL: https://metacpan.org/dist/Net-DNS/

Please consult the package updates policy before you issue an update to a
stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/


More information about the service that created this bug can be found at:
https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring


Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.


Based on the information from Anitya:
https://release-monitoring.org/project/3147/


To change the monitoring settings for the project, please visit:
https://src.fedoraproject.org/rpms/perl-Net-DNS


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

Report this comment as SPAM: 
https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202251788%23c3
--
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40 Change Proposal: Move /var/run selinux-policy entries to /run (Self-Contained)

2023-12-24 Thread Christian Glombek 
Prior art in https://github.com/fedora-selinux/selinux-policy/pull/243 for
reference

Christian Glombek (he/him)

Senior Software Engineer

Red Hat GmbH 


cglom...@redhat.com 


Red Hat GmbH , Registered seat:
Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill,
Amy Ross  




On Sun, Dec 24, 2023 at 3:52 PM Aoife Moloney  wrote:

> wiki ->
> https://fedoraproject.org/wiki/Changes/Move_var_run_selinux_policy_entries_to_run
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> Actual path for system runtime files moved from /var/run to /run some
> 10 years ago [1], but the policy has been managed since then in a way
> that keeps the old entries and have updates still with the incorrect
> path while the real path is handled by file equivalency feature. This
> can confuse sysadmins not to be sure which path should be actually
> used and can also effect in userspace tools not working properly [2].
>
> [1] https://fedoraproject.org/wiki/Features/UsrMove
>
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=2241366
>
> == Owner ==
> * Name: Zdenek Pytela
> * Email: zpyt...@redhat.com
>
>
> == Detailed Description ==
> The change actually means just replacing "/run = /var/run"
> file-context equivalency rules with "/var/run = /run". While the
> change as such is quite simple, it can have effect on other components
> using their own selinux policy with file-context entries.
>
> == Feedback ==
>
> == Benefit to Fedora ==
> Removing technical debt which originated 10 years ago.
> More straightforward handling of file-context entries in the /run
> filesystem.
>
>
> == Scope ==
> * Proposal owners:
> ** Add all relevant patches to upstream repository
> ** Ensure the system boots with the targeted policy
> ** Ensure the system boots with the mls policy
> ** Ensure updates from older releases work, more specifically with
> custom selinux packages installed.
>
> * Other developers:
> ** Developers of custom selinux policies need to confirm system updates
> work.
>
> * Release engineering: [https://pagure.io/releng/issues #Releng issue
> number] (a check of an impact with Release Engineering is needed)
>
> * Policies and guidelines: No update required.
>
> * Trademark approval: N/A (not needed for this Change)
>
> * Alignment with Objectives:
>
>
> == Upgrade/compatibility impact ==
> Users can be affected by this change if they use a local policy with
> file-context entries in /run which occurs quite rarely, but is
> possible.
>
>
>
> == How To Test ==
> * Install a new system and check for error messages and audit records.
> * Update an existing system and check if all updates completed without an
> error.
> * Optionally, install and boot the selinux-policy-mls package.
> * Check for errors reported by dnf or rpm.
>
>
>
> == User Experience ==
> There should be no visible change for end users.
>
> The change should be transparent, without any further action needed on
> the system. System admins may need to take an action based on
> compatibility with the changes.
>
>
> == Dependencies ==
> Components with a custom selinux policy: container-selinux pcp cockpit
>
> == Contingency Plan ==
> * Contingency mechanism: Revert all changes in case of serious
> problems with updates.
> * Contingency deadline: 2024-02-06 (Branch Fedora Linux 40 from Rawhide)
> * Blocks release? No
> * Blocks product? No
>
> == Documentation ==
> To be added later.
>
> == Release Notes ==
>
>
>
> --
> Aoife Moloney
>
> Fedora Operations Architect
>
> Fedora Project
>
> Matrix: @amoloney:fedora.im
>
> IRC: amoloney
> --
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to
> devel-announce-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:

F40 Change Proposal: Move /var/run selinux-policy entries to /run (Self-Contained)

2023-12-24 Thread Aoife Moloney 
wiki -> 
https://fedoraproject.org/wiki/Changes/Move_var_run_selinux_policy_entries_to_run

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

== Summary ==
Actual path for system runtime files moved from /var/run to /run some
10 years ago [1], but the policy has been managed since then in a way
that keeps the old entries and have updates still with the incorrect
path while the real path is handled by file equivalency feature. This
can confuse sysadmins not to be sure which path should be actually
used and can also effect in userspace tools not working properly [2].

[1] https://fedoraproject.org/wiki/Features/UsrMove

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2241366

== Owner ==
* Name: Zdenek Pytela
* Email: zpyt...@redhat.com


== Detailed Description ==
The change actually means just replacing "/run = /var/run"
file-context equivalency rules with "/var/run = /run". While the
change as such is quite simple, it can have effect on other components
using their own selinux policy with file-context entries.

== Feedback ==

== Benefit to Fedora ==
Removing technical debt which originated 10 years ago.
More straightforward handling of file-context entries in the /run filesystem.


== Scope ==
* Proposal owners:
** Add all relevant patches to upstream repository
** Ensure the system boots with the targeted policy
** Ensure the system boots with the mls policy
** Ensure updates from older releases work, more specifically with
custom selinux packages installed.

* Other developers:
** Developers of custom selinux policies need to confirm system updates work.

* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)

* Policies and guidelines: No update required.

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

* Alignment with Objectives:


== Upgrade/compatibility impact ==
Users can be affected by this change if they use a local policy with
file-context entries in /run which occurs quite rarely, but is
possible.



== How To Test ==
* Install a new system and check for error messages and audit records.
* Update an existing system and check if all updates completed without an error.
* Optionally, install and boot the selinux-policy-mls package.
* Check for errors reported by dnf or rpm.



== User Experience ==
There should be no visible change for end users.

The change should be transparent, without any further action needed on
the system. System admins may need to take an action based on
compatibility with the changes.


== Dependencies ==
Components with a custom selinux policy: container-selinux pcp cockpit

== Contingency Plan ==
* Contingency mechanism: Revert all changes in case of serious
problems with updates.
* Contingency deadline: 2024-02-06 (Branch Fedora Linux 40 from Rawhide)
* Blocks release? No
* Blocks product? No

== Documentation ==
To be added later.

== Release Notes ==



-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

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

Re: F40 Change Proposal: SPDC Licence Phase 3 (System-Wide)

2023-12-24 Thread Aoife Moloney 
Correction to title - SPDX Licence Phase 3
--
___
devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-annou...@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

F40 Change Proposal: Move /var/run selinux-policy entries to /run (Self-Contained)

2023-12-24 Thread Aoife Moloney 
wiki -> 
https://fedoraproject.org/wiki/Changes/Move_var_run_selinux_policy_entries_to_run

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

== Summary ==
Actual path for system runtime files moved from /var/run to /run some
10 years ago [1], but the policy has been managed since then in a way
that keeps the old entries and have updates still with the incorrect
path while the real path is handled by file equivalency feature. This
can confuse sysadmins not to be sure which path should be actually
used and can also effect in userspace tools not working properly [2].

[1] https://fedoraproject.org/wiki/Features/UsrMove

[2] https://bugzilla.redhat.com/show_bug.cgi?id=2241366

== Owner ==
* Name: Zdenek Pytela
* Email: zpyt...@redhat.com


== Detailed Description ==
The change actually means just replacing "/run = /var/run"
file-context equivalency rules with "/var/run = /run". While the
change as such is quite simple, it can have effect on other components
using their own selinux policy with file-context entries.

== Feedback ==

== Benefit to Fedora ==
Removing technical debt which originated 10 years ago.
More straightforward handling of file-context entries in the /run filesystem.


== Scope ==
* Proposal owners:
** Add all relevant patches to upstream repository
** Ensure the system boots with the targeted policy
** Ensure the system boots with the mls policy
** Ensure updates from older releases work, more specifically with
custom selinux packages installed.

* Other developers:
** Developers of custom selinux policies need to confirm system updates work.

* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] (a check of an impact with Release Engineering is needed)

* Policies and guidelines: No update required.

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

* Alignment with Objectives:


== Upgrade/compatibility impact ==
Users can be affected by this change if they use a local policy with
file-context entries in /run which occurs quite rarely, but is
possible.



== How To Test ==
* Install a new system and check for error messages and audit records.
* Update an existing system and check if all updates completed without an error.
* Optionally, install and boot the selinux-policy-mls package.
* Check for errors reported by dnf or rpm.



== User Experience ==
There should be no visible change for end users.

The change should be transparent, without any further action needed on
the system. System admins may need to take an action based on
compatibility with the changes.


== Dependencies ==
Components with a custom selinux policy: container-selinux pcp cockpit

== Contingency Plan ==
* Contingency mechanism: Revert all changes in case of serious
problems with updates.
* Contingency deadline: 2024-02-06 (Branch Fedora Linux 40 from Rawhide)
* Blocks release? No
* Blocks product? No

== Documentation ==
To be added later.

== Release Notes ==



-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

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

Re: F40 Change Proposal: SPDC Licence Phase 3 (System-Wide)

2023-12-24 Thread Aoife Moloney 
Correction to title - SPDX Licence Phase 3
--
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

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

2023-12-24 Thread Leon Fauster via devel 

Am 24.12.23 um 15:03 schrieb Robert Nichols:

On 12/23/23 16:40, 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 phoneto spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


I hope that's per SSID and not per AP, or else that would mean that as a 
device roams among access points in my network it would keep generating 
new MAC addresses that are not known to my DHCP server?



https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/blob/main/src/libnm-core-impl/nm-setting-wireless.c#L1598




It's bad enough that I can't know in advance what MAC address a new 
device will be using, and might thus have to decide which, of several 
possible DHCP requests that might appear, is the one to which I want to 
grant access.




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

F40 Change Proposal: SPDC Licence Phase 3 (System-Wide)

2023-12-24 Thread Aoife Moloney 
wiki -> https://fedoraproject.org/wiki/Changes/RemovePythonMockUsage

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


== Summary ==

The third phase of transition from using Fedora's short names for
licenses to [https://spdx.org/licenses/ SPDX identifiers] in the
License: field of Fedora package spec files. This phase focuses on
finishing migrating packages from ELN set. We still do not expect that
all packages from Fedora Linux will be migrated in this phase.

== Owner ==

* Name: [[User:msuchy| Miroslav Suchý]], [[User:jlovejoy| Jilayne
Lovejoy]], [[User:dcantrell| David Cantrell]], [[User:ref| Richard
Fontana]]

* Email: msu...@redhat.com, dcantr...@redhat.com, jlove...@redhat.com,
rfont...@redhat.com




== Detailed Description ==

This is follow-up of [[Changes/SPDX_Licenses_Phase_2|Phase 2]]. During
this phase, all remaining packages should be migrated to use SPDX
license identifiers in the License: field of the package spec file.

So far, package maintainers have been updating their packages in
accordance with the guidance provided at
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/
and filing issues in the
[https://gitlab.com/fedora/legal/fedora-license-data
fedora-license-data repo]. Miroslav has been tracking how many
packages that have been updated. Given the large number of packages in
Fedora, this progress is good, but slow.

The intake of newly discovered licenses is still more than we are able
to process. We want to focus on adding the new license to both
fedora-license-data and SPDX.org list.

At the same time, we want to focus on the ELN subset of Fedora and
cooperate with maintainers of these packages to finish the migration
of these packages.

This Change will be followed by [[Changes/SPDX_Licenses_Phase_4|Phase
4]], where we want to finish the migration of the remaining Fedora
packages.

== Feedback ==

See [[Changes/SPDX_Licenses_Phase_1#Feedback|feedback section of Phase 1]]

Discussions on the mailing list:
* 
[https://lists.fedoraproject.org/archives/search?q=SPDX+statistics=1=devel%40lists.fedoraproject.org=date-desc
regular SPDX Statistics]
* 
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3TGCSROJTSX5PXZLKOHCOMVIBTZDORNS/
SPDX - How to handle MIT and BSD]

Challenges:
* license-fedora2spdx tool uses mapping of legacy Fedora short names
to SPDX identifiers using the
[https://gitlab.com/fedora/legal/fedora-license-data/-/tree/main
fedora-license-data] to suggest SPDX identifiers. Where there is an
apparent one-to-one mapping, the package maintainer could simply
update the License field: and move on.
* for many packages, particularly packages that use "umbrella" legacy
short names that may refer to a large set of unrelated or loosely
related licenses, further inspection will be needed. Currently, Fedora
documentation provides sparse advice on how to do this inspection and
thus, a range of methods are used.

Progress to date:
[https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit#gid=0
Burndow chart]

== Benefit to Fedora ==

The use of standardized identifiers for licenses will align Fedora
with other distributions and facilitates efficient and reliable
identification of licenses. Depending on the level of diligence done
in this transition, Fedora could be positioned as a leader and
contributor to better license information upstream (of Fedora).


== Scope ==
* Change Owners:
** Continue adding newly found licenses to fedora-license-data and to
SPDX.org list.
** Continue to report progress
** Focus on the ELN subset of Fedora.

* Other developers:
** All packages (during the package review) should use the SPDX
expression. - this is redundant as this has already been approved
since Phase 1, but it should be reminded.
** Migrate the existing License tag from a short name to an SPDX expression.

* Release engineering: nothing

* Policies and guidelines: all done in previous phases

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

* Alignment with Objectives:


== Upgrade/compatibility impact ==

License strings are not used anything in run time. This change will
not affect the upgrade or runtime of Fedora.

During the transition period, developer tools like rpminspect,
licensecheck, etc. may produce false negatives. And we have to define
a date where we flip these tools from old Fedora's short names to the
SPDX formula.


== How To Test ==

See [[Changes/SPDX_Licenses_Phase_1#How_To_Test|How to test section of Phase 1]]


== User Experience ==

Users should be able to use standard software tools that audit
licenses. E.g. for Software Bills of Materials.


== Dependencies ==

No other dependencies.


== Contingency Plan ==

* Contingency mechanism: There will be no way back. We are already

F40 Change Proposal: SPDC Licence Phase 3 (System-Wide)

2023-12-24 Thread Aoife Moloney 
wiki -> https://fedoraproject.org/wiki/Changes/RemovePythonMockUsage

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


== Summary ==

The third phase of transition from using Fedora's short names for
licenses to [https://spdx.org/licenses/ SPDX identifiers] in the
License: field of Fedora package spec files. This phase focuses on
finishing migrating packages from ELN set. We still do not expect that
all packages from Fedora Linux will be migrated in this phase.

== Owner ==

* Name: [[User:msuchy| Miroslav Suchý]], [[User:jlovejoy| Jilayne
Lovejoy]], [[User:dcantrell| David Cantrell]], [[User:ref| Richard
Fontana]]

* Email: msu...@redhat.com, dcantr...@redhat.com, jlove...@redhat.com,
rfont...@redhat.com




== Detailed Description ==

This is follow-up of [[Changes/SPDX_Licenses_Phase_2|Phase 2]]. During
this phase, all remaining packages should be migrated to use SPDX
license identifiers in the License: field of the package spec file.

So far, package maintainers have been updating their packages in
accordance with the guidance provided at
https://docs.fedoraproject.org/en-US/legal/update-existing-packages/
and filing issues in the
[https://gitlab.com/fedora/legal/fedora-license-data
fedora-license-data repo]. Miroslav has been tracking how many
packages that have been updated. Given the large number of packages in
Fedora, this progress is good, but slow.

The intake of newly discovered licenses is still more than we are able
to process. We want to focus on adding the new license to both
fedora-license-data and SPDX.org list.

At the same time, we want to focus on the ELN subset of Fedora and
cooperate with maintainers of these packages to finish the migration
of these packages.

This Change will be followed by [[Changes/SPDX_Licenses_Phase_4|Phase
4]], where we want to finish the migration of the remaining Fedora
packages.

== Feedback ==

See [[Changes/SPDX_Licenses_Phase_1#Feedback|feedback section of Phase 1]]

Discussions on the mailing list:
* 
[https://lists.fedoraproject.org/archives/search?q=SPDX+statistics=1=devel%40lists.fedoraproject.org=date-desc
regular SPDX Statistics]
* 
[https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/3TGCSROJTSX5PXZLKOHCOMVIBTZDORNS/
SPDX - How to handle MIT and BSD]

Challenges:
* license-fedora2spdx tool uses mapping of legacy Fedora short names
to SPDX identifiers using the
[https://gitlab.com/fedora/legal/fedora-license-data/-/tree/main
fedora-license-data] to suggest SPDX identifiers. Where there is an
apparent one-to-one mapping, the package maintainer could simply
update the License field: and move on.
* for many packages, particularly packages that use "umbrella" legacy
short names that may refer to a large set of unrelated or loosely
related licenses, further inspection will be needed. Currently, Fedora
documentation provides sparse advice on how to do this inspection and
thus, a range of methods are used.

Progress to date:
[https://docs.google.com/spreadsheets/d/1QVMEzXWML-6_Mrlln02axFAaRKCQ8zE807rpCjus-8s/edit#gid=0
Burndow chart]

== Benefit to Fedora ==

The use of standardized identifiers for licenses will align Fedora
with other distributions and facilitates efficient and reliable
identification of licenses. Depending on the level of diligence done
in this transition, Fedora could be positioned as a leader and
contributor to better license information upstream (of Fedora).


== Scope ==
* Change Owners:
** Continue adding newly found licenses to fedora-license-data and to
SPDX.org list.
** Continue to report progress
** Focus on the ELN subset of Fedora.

* Other developers:
** All packages (during the package review) should use the SPDX
expression. - this is redundant as this has already been approved
since Phase 1, but it should be reminded.
** Migrate the existing License tag from a short name to an SPDX expression.

* Release engineering: nothing

* Policies and guidelines: all done in previous phases

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

* Alignment with Objectives:


== Upgrade/compatibility impact ==

License strings are not used anything in run time. This change will
not affect the upgrade or runtime of Fedora.

During the transition period, developer tools like rpminspect,
licensecheck, etc. may produce false negatives. And we have to define
a date where we flip these tools from old Fedora's short names to the
SPDX formula.


== How To Test ==

See [[Changes/SPDX_Licenses_Phase_1#How_To_Test|How to test section of Phase 1]]


== User Experience ==

Users should be able to use standard software tools that audit
licenses. E.g. for Software Bills of Materials.


== Dependencies ==

No other dependencies.


== Contingency Plan ==

* Contingency mechanism: There will be no way back. We are already

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

2023-12-24 Thread Robert Nichols 

On 12/23/23 16:40, 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 phoneto spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


I hope that's per SSID and not per AP, or else that would mean that as a device 
roams among access points in my network it would keep generating new MAC 
addresses that are not known to my DHCP server?

It's bad enough that I can't know in advance what MAC address a new device will 
be using, and might thus have to decide which, of several possible DHCP 
requests that might appear, is the one to which I want to grant access.

--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete 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: 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

Fedora rawhide compose report: 20231224.n.0 changes

2023-12-24 Thread Fedora Rawhide Report 
OLD: Fedora-Rawhide-20231223.n.0
NEW: Fedora-Rawhide-20231224.n.0

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

Size of added packages:  128.08 KiB
Size of dropped packages:0 B
Size of upgraded packages:   1.53 GiB
Size of downgraded packages: 0 B

Size change of upgraded packages:   12.53 MiB
Size change of downgraded packages: 0 B

= ADDED IMAGES =
Image: Kinoite dvd-ostree aarch64
Path: Kinoite/aarch64/iso/Fedora-Kinoite-ostree-aarch64-Rawhide-20231224.n.0.iso

= DROPPED IMAGES =
Image: Silverblue dvd-ostree x86_64
Path: 
Silverblue/x86_64/iso/Fedora-Silverblue-ostree-x86_64-Rawhide-20231223.n.0.iso
Image: Silverblue dvd-ostree aarch64
Path: 
Silverblue/aarch64/iso/Fedora-Silverblue-ostree-aarch64-Rawhide-20231223.n.0.iso
Image: Silverblue dvd-ostree ppc64le
Path: 
Silverblue/ppc64le/iso/Fedora-Silverblue-ostree-ppc64le-Rawhide-20231223.n.0.iso

= ADDED PACKAGES =
Package: labwc-menu-generator-0~git20231031.d7c8107-1.fc40
Summary: Menu generator for labwc
RPMs:labwc-menu-generator
Size:128.08 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  conda-23.11.0-2.fc40
Old package:  conda-23.11.0-1.fc40
Summary:  Cross-platform, Python-agnostic binary package manager
RPMs: conda conda-tests python3-conda
Size: 15.91 MiB
Size change:  1.77 KiB
Changelog:
  * Sun Dec 24 2023 Orion Poplawski  - 23.11.0-2
  - Preserve hook_source_path as a Path object


Package:  cppcheck-2.13.0-1.fc40
Old package:  cppcheck-2.12.1-1.fc40
Summary:  Tool for static C/C++ code analysis
RPMs: cppcheck cppcheck-gui cppcheck-htmlreport
Size: 18.76 MiB
Size change:  241.06 KiB
Changelog:
  * Sat Dec 23 2023 Wolfgang St??ggl  - 2.13.0-1
  - Update to 2.13.0


Package:  eegdev-0.2-26.fc40
Old package:  eegdev-0.2-17.fc40
Summary:  Library to acquire data from various EEG recording devices
RPMs: eegdev eegdev-devel eegdev-plugins
Size: 407.38 KiB
Size change:  181 B
Changelog:
  * Sat Dec 16 2023 Sandro  - 0.2-18
  - Drop i686 support

  * Thu Dec 21 2023 Sandro  - 0.2-19
  - Make sure config.h is included first (RHBZ#2225765)


Package:  fedrq-0.13.0-1.fc40
Old package:  fedrq-0.12.0-1.fc40
Summary:  A tool to query the Fedora and EPEL repositories
RPMs: fedrq
Size: 185.87 KiB
Size change:  4.41 KiB
Changelog:
  * Mon Dec 18 2023 Maxwell G  - 0.13.0-1
  - Update to 0.13.0.


Package:  gjs-1.78.1-2.fc40
Old package:  gjs-1.78.1-1.fc40
Summary:  Javascript Bindings for GNOME
RPMs: gjs gjs-devel gjs-tests
Size: 4.17 MiB
Size change:  2.08 KiB
Changelog:
  * Sat Dec 23 2023 Frantisek Zatloukal  - 1.78.1-2
  - Rebuild against mozjs115-115.6.0-1


Package:  kdsingleapplication-1.1.0-1.fc40
Old package:  kdsingleapplication-1.0.0-2.fc40
Summary:  KDAB's helper class for single-instance policy applications
RPMs: kdsingleapplication-qt5 kdsingleapplication-qt5-devel 
kdsingleapplication-qt6 kdsingleapplication-qt6-devel
Size: 444.22 KiB
Size change:  7.82 KiB
Changelog:
  * Sat Dec 23 2023 Ondrej Mosnek  - 1.0.0-3
  - Fix macro recursion for cmake_args

  * Sat Dec 23 2023 Ondrej Mosnek  - 1.1.0-1
  - Update to version 1.1.0 (fedora#2255689)


Package:  komikku-1.32.0-1.fc40
Old package:  komikku-1.31.0-1.fc40
Summary:  A manga reader for GNOME
RPMs: komikku
Size: 1.36 MiB
Size change:  7.17 KiB
Changelog:
  * Sat Dec 23 2023 Packit  - 1.32.0-1
  - [packit] 1.32.0 upstream release
  - Resolves rhbz#2255681


Package:  libssh-0.10.6-2.fc40
Old package:  libssh-0.10.6-1.fc40
Summary:  A library implementing the SSH protocol
RPMs: libssh libssh-config libssh-devel
Size: 1.28 MiB
Size change:  891 B
Changelog:
  * Fri Dec 22 2023 Jakub Jelen  - 0.10.6-2
  - Fix regression in IPv6 hosntames parsing


Package:  moarvm-2023.12-1.fc40
Old package:  moarvm-2023.10-1.fc40
Summary:  Metamodel On A Runtime Virtual Machine
RPMs: moarvm moarvm-devel
Size: 10.10 MiB
Size change:  -22.62 KiB
Changelog:
  * Wed Nov 22 2023 topazus  - 2023.10-2
  - add packit configuration file

  * Sat Dec 23 2023 Packit  - 2023.12-1
  - [packit] 2023.12 upstream release
  - Resolves rhbz#2250948


Package:  nqp-2023.12-1.fc40
Old package:  nqp-2023.10-1.fc40
Summary:  Perl 6 compiler implementation that runs on MoarVM
RPMs: nqp
Size: 2.74 MiB
Size change:  -2.50 KiB
Changelog:
  * Sat Nov 18 2023 topazus  - 2023.10-2
  - setup packit automation

  * Sat Dec 23 2023 Packit  - 2023.12-1
  - [packit] 2023.12 upstream release
  - Resolves rhbz#2250943


Package:  nss-3.96.1-1.fc40
Old package:  nss-3.95.0-1.fc40
Summary:  Network Security Services
RPMs: nspr nspr-devel nss nss-devel nss-pkcs11-devel nss-softokn 
nss-softokn-devel nss-softokn