Update python-musicbrainzngs by a proven packager and request for adding a co-maintainer to the package

[Johannes Lips]

Hi all,

the package python-musicbrainzngs [1] has a long-standing bug [2] and is not 
upgraded to the latest version, which creates all sorts of issues for dependent 
packages. Therefore, I would like to ask if a proven-package could initiate an 
update. There's already a pull-request at 
https://src.fedoraproject.org/rpms/python-musicbrainzngs/pull-request/1
If possible it would be great if the package could get some co-maintainers in 
order to prevent a situation like this from happening again.

Thanks in advance
hannes

[1] https://src.fedoraproject.org/rpms/python-musicbrainzngs
[2 ] https://bugzilla.redhat.com/show_bug.cgi?id=1685216
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Michel Alexandre Salim]

Hi all,

On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/FixRescueMode
> 
> == Summary ==
> Fedora defaults to locking the root account, which is needed by
> single-user mode. This Change uses `sulogin --force` so the password
> request is bypassed under this circumstance.
> 
Thanks for all the feedback. Going to do a reply here rather than in
individual subthreads since I'm responding to several suggestions.

For those who thinks this is a security concern (granted, not a new one,
but one that is more convenient), requiring some password seems to be
the way out

- do we want to allow any /local/ %wheel users to log in?
- or do we want to use a recovery passphrase of some sort?
- TPM dependencies might not be appropriate

I'm leaning towards not rushing this and delaying to F37; Chris Murphy
raised a good question on whether the current bypass is fine for CoreOS
or not.

For F36 - I agree that it's better to *not* have a rescue mode than a
broken one. How about this as an end state we can realistically achieve:
- if the root password is set, rescue mode should appear in the GRUB
  menu
- if the root password is not set
  - rescue mode should not be listed
  - if someone tries to invoke it, it should display an error rather
than prompting for a non-existent password

If that seems reasonable, we can figure out where to put the hooks next.

Best regards,
  
-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


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

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Colin Walters]

On Wed, Dec 8, 2021, at 1:28 PM, Chris Murphy wrote:
> On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering  
> wrote:
>>
>> On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>>
>> > Latest systemd versions have been getting some support for the low-level
>> > parts, i.e. the low-level encrypted-secret storage. But we're missing the
>> > upper parts, i.e. how to actually use and update the passwords. I didn't
>> > even mention this, because we don't have a comprehensive story yet.
>> > I think it'd be necessary to write some pam module and/or authentication
>> > helper from scratch. It's probably not too much work, but nobody has
>> > signed up to do this.
>>
>> So here's what I'd suggest: let's define a group (my suggestion: let's
>> repurpose "wheel" for that) that has the effect that the passwords of
>> any user in it are also accepted as password for the root user,
>> implicitly. We'd have to add some small infra to collect these
>> passwords, and encrypt/sign them with TPM2, then propagate to the ESP
>> or to some EFI var or so, so that they can be honoured already in the
>> initrd.I mean in addition this is tantamount to moving `/etc/shadow` into 
>> the tpm, right?
>
> I'm skeptical of any TPM2 dependency because systems still do not come
> with them, in particular the significant minority of systems that are
> not part of the "made for Windows" marketing program that compels
> manufacturers to follow the Windows Hardware Compatibility Program.
> And yes you can install Windows 11 without a TPM, it just won't be
> preinstalled, and that make/model doesn't qualify for whatever Windows
> marketing programs OEM's get for having certified hardware. That's
> aside from the fact there's TPM 2.0 in hardware today that the kernel
> doesn't support and likely won't ever support.

Right.  I am in favor of having tight integration with the TPM of course, but 
it can't be used exclusively.

In particular, I think about half the posters in this thread are thinking of 
the desktop case, but the problem can easily happen on virtualized servers too 
- that's why we ship the bits we do in Fedora CoreOS.  And we need to consider 
public and private cloud (e.g. OpenStack/vSphere) instances which were 
provisioned without UEFI, as well as ppc64le and s390x.  And still today, the 
default for `virt-install` on x86_64 is BIOS.

So I'll just re-surface my idea of having the bootloader either pass 
information about its "locked" state to the kernel and to systemd, or have some 
sort of more declarative easily parsable config file for this that systemd 
could read (i.e. not `grub.cfg`).  The former seems better.  Either way there's 
just one "source of truth" and admins who *do* want to lock the system against 
casual keyboard interactive changes don't need to do it in two places.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora-Rawhide-20211208.n.0 compose check report

[Fedora compose checker]

No missing expected images.

Compose FAILS proposed Rawhide gating check!
1 of 43 required tests failed
openQA tests matching unsatisfied gating requirements shown with **GATING** 
below

Failed openQA tests: 6/208 (x86_64), 7/142 (aarch64)

New failures (same test not failed in Fedora-Rawhide-20211207.n.0):

ID: 1081010 Test: x86_64 Workstation-live-iso eog
URL: https://openqa.fedoraproject.org/tests/1081010
ID: 1081059 Test: x86_64 Silverblue-dvd_ostree-iso evince
URL: https://openqa.fedoraproject.org/tests/1081059
ID: 1081061 Test: x86_64 Silverblue-dvd_ostree-iso eog
URL: https://openqa.fedoraproject.org/tests/1081061
ID: 1081071 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi 
**GATING**
URL: https://openqa.fedoraproject.org/tests/1081071
ID: 1081095 Test: aarch64 Server-dvd-iso install_default_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1081095
ID: 1081123 Test: aarch64 Server-dvd-iso install_blivet_resize_lvm@uefi
URL: https://openqa.fedoraproject.org/tests/1081123
ID: 1081148 Test: aarch64 Workstation-raw_xz-raw.xz evince@uefi
URL: https://openqa.fedoraproject.org/tests/1081148
ID: 1081236 Test: x86_64 universal upgrade_minimal_uefi@uefi
URL: https://openqa.fedoraproject.org/tests/1081236
ID: 1081259 Test: aarch64 universal upgrade_server_domain_controller@uefi
URL: https://openqa.fedoraproject.org/tests/1081259
ID: 1081288 Test: aarch64 universal upgrade_realmd_client@uefi
URL: https://openqa.fedoraproject.org/tests/1081288

Old failures (same test failed in Fedora-Rawhide-20211207.n.0):

ID: 1081036 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/1081036
ID: 1081149 Test: aarch64 Workstation-raw_xz-raw.xz gedit@uefi
URL: https://openqa.fedoraproject.org/tests/1081149
ID: 1081154 Test: aarch64 Workstation-raw_xz-raw.xz eog@uefi
URL: https://openqa.fedoraproject.org/tests/1081154

Soft failed openQA tests: 1/142 (aarch64), 3/208 (x86_64)
(Tests completed, but using a workaround for a known bug)

New soft failures (same test not soft failed in Fedora-Rawhide-20211207.n.0):

ID: 1081163 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1081163

Old soft failures (same test soft failed in Fedora-Rawhide-20211207.n.0):

ID: 1081025 Test: x86_64 Workstation-live-iso gedit
URL: https://openqa.fedoraproject.org/tests/1081025
ID: 1081060 Test: x86_64 Silverblue-dvd_ostree-iso gedit
URL: https://openqa.fedoraproject.org/tests/1081060
ID: 1081210 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/1081210

Passed openQA tests: 110/142 (aarch64), 199/208 (x86_64)

New passes (same test not passed in Fedora-Rawhide-20211207.n.0):

ID: 1081082 Test: aarch64 Server-dvd-iso anaconda_help@uefi
URL: https://openqa.fedoraproject.org/tests/1081082
ID: 1081138 Test: aarch64 Workstation-raw_xz-raw.xz 
install_arm_image_deployment_upload@uefi
URL: https://openqa.fedoraproject.org/tests/1081138
ID: 1081192 Test: x86_64 universal support_server
URL: https://openqa.fedoraproject.org/tests/1081192
ID: 1081200 Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/1081200
ID: 1081244 Test: aarch64 universal install_asian_language@uefi
URL: https://openqa.fedoraproject.org/tests/1081244

Skipped non-gating openQA tests: 24 of 350

Installed system changes in test x86_64 Server-boot-iso install_default@uefi: 
System load changed from 0.12 to 0.24
Previous test data: https://openqa.fedoraproject.org/tests/1080040#downloads
Current test data: https://openqa.fedoraproject.org/tests/1080942#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default@uefi: 
1 packages(s) added since previous compose: biosdevname
1 services(s) added since previous compose: fwupd.service
System load changed from 0.63 to 0.39
Previous test data: https://openqa.fedoraproject.org/tests/1080044#downloads
Current test data: https://openqa.fedoraproject.org/tests/1081002#downloads

Installed system changes in test x86_64 Workstation-live-iso 
install_default_upload: 
1 packages(s) added since previous compose: biosdevname
System load changed from 0.56 to 0.77
Previous test data: https://openqa.fedoraproject.org/tests/1080045#downloads
Current test data: https://openqa.fedoraproject.org/tests/1081004#downloads

Installed system changes in test x86_64 KDE-live-iso install_default_upload: 
1 packages(s) added since previous compose: biosdevname
System load changed from 1.42 to 1.06
Previous test data: https://openqa.fedoraproject.org/tests/1079307#downloads
Current test data: https://openqa.fedoraproject.org/tests/1081028#downloads

Installed system changes in test x86_64 KDE-live-iso install_default@uefi: 
1 packages(s) added since previous compose: biosdevname
Previous test data: https://openqa.fedoraproject.org/tests/1079309#

Who maintains virtio-win repos?

[Chris Adams]

Is there a contact for the virtio-win repos?  I looked to see if there
was anything in Bugzilla that looked relevant, but didn't find anything.
I'm talking about this:

https://fedorapeople.org/groups/virt/virtio-win/repo/

The repos need work; there have been new release RPMs added, but the
repodata was not rebuilt (so the updates aren't visible to dnf).
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Fedora rawhide compose report: 20211208.n.0 changes

[Fedora Rawhide Report]

OLD: Fedora-Rawhide-20211207.n.0
NEW: Fedora-Rawhide-20211208.n.0

= SUMMARY =
Added images:7
Dropped images:  0
Added packages:  6
Dropped packages:0
Upgraded packages:   105
Downgraded packages: 0

Size of added packages:  3.78 GiB
Size of dropped packages:0 B
Size of upgraded packages:   2.58 GiB
Size of downgraded packages: 0 B

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

= ADDED IMAGES =
Image: Container_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Base-Rawhide-20211208.n.0.s390x.tar.xz
Image: Cloud_Base raw-xz s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20211208.n.0.s390x.raw.xz
Image: Server boot s390x
Path: Server/s390x/iso/Fedora-Server-netinst-s390x-Rawhide-20211208.n.0.iso
Image: Container_Minimal_Base docker s390x
Path: 
Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20211208.n.0.s390x.tar.xz
Image: Cloud_Base qcow2 s390x
Path: Cloud/s390x/images/Fedora-Cloud-Base-Rawhide-20211208.n.0.s390x.qcow2
Image: Everything boot s390x
Path: 
Everything/s390x/iso/Fedora-Everything-netinst-s390x-Rawhide-20211208.n.0.iso
Image: Server dvd s390x
Path: Server/s390x/iso/Fedora-Server-dvd-s390x-Rawhide-20211208.n.0.iso

= DROPPED IMAGES =

= ADDED PACKAGES =
Package: gojq-0.12.6-1.fc36
Summary: Pure Go implementation of jq
RPMs:gojq golang-github-itchyny-gojq-devel
Size:6.35 MiB

Package: golang-github-letsencrypt-challtestsrv-1.2.1-1.fc36
Summary: Small TEST-ONLY server for mock ACME challenges
RPMs:golang-github-letsencrypt-challtestsrv-devel
Size:23.86 KiB

Package: golang-github-yuin-goldmark-emoji-1.0.1-1.fc36
Summary: An emoji extension for the goldmark markdown parser
RPMs:golang-github-yuin-goldmark-emoji-devel
Size:36.66 KiB

Package: java-17-openjdk-1:17.0.1.0.12-8.fc36
Summary: OpenJDK 17 Runtime Environment
RPMs:java-17-openjdk java-17-openjdk-demo java-17-openjdk-demo-fastdebug 
java-17-openjdk-demo-slowdebug java-17-openjdk-devel 
java-17-openjdk-devel-fastdebug java-17-openjdk-devel-slowdebug 
java-17-openjdk-fastdebug java-17-openjdk-headless 
java-17-openjdk-headless-fastdebug java-17-openjdk-headless-slowdebug 
java-17-openjdk-javadoc java-17-openjdk-javadoc-zip java-17-openjdk-jmods 
java-17-openjdk-jmods-fastdebug java-17-openjdk-jmods-slowdebug 
java-17-openjdk-slowdebug java-17-openjdk-src java-17-openjdk-src-fastdebug 
java-17-openjdk-src-slowdebug java-17-openjdk-static-libs 
java-17-openjdk-static-libs-fastdebug java-17-openjdk-static-libs-slowdebug
Size:3.77 GiB

Package: rust-html-escape-0.2.9-1.fc36
Summary: Library for escaping special characters and unescaping HTML entities 
in HTML
RPMs:rust-html-escape+default-devel rust-html-escape+std-devel 
rust-html-escape-devel
Size:49.91 KiB

Package: rust-smallbitvec-2.5.1-1.fc36
Summary: Bit vector optimized for size and inline storage
RPMs:rust-smallbitvec+default-devel rust-smallbitvec-devel
Size:29.48 KiB


= DROPPED PACKAGES =

= UPGRADED PACKAGES =
Package:  Lmod-8.6-1.fc36
Old package:  Lmod-8.5.26-1.fc36
Summary:  Environmental Modules System in Lua
RPMs: Lmod
Size: 1.11 MiB
Size change:  -23 B
Changelog:
  * Fri Dec 03 2021 Orion Poplawski  - 8.5.28-1
  - Update to 8.5.28

  * Tue Dec 07 2021 Orion Poplawski  - 8.6-1
  - Update to 8.6


Package:  ansible-core-2.12.1-1.fc36
Old package:  ansible-core-2.12.0-1.fc36
Summary:  A radically simple IT automation system
RPMs: ansible-core ansible-core-doc
Size: 3.84 MiB
Size change:  -2.98 KiB
Changelog:
  * Tue Dec 07 2021 Kevin Fenzi  - 2.12.1-1
  - Update to 2.12.1. Fixes rhbz#2029598


Package:  ansible-freeipa-1.5.0-1.fc36
Old package:  ansible-freeipa-0.4.0-1.fc36
Summary:  Roles and playbooks to deploy FreeIPA servers, replicas and 
clients
RPMs: ansible-freeipa ansible-freeipa-tests
Size: 356.46 KiB
Size change:  1.54 KiB
Changelog:
  * Tue Dec 07 2021 Thomas Woerner  - 1.5.0-1
  - Update to version 1.5.0
https://github.com/freeipa/ansible-freeipa/releases/tag/v1.5.0


Package:  applet-window-buttons-0.10.1-1.fc36
Old package:  applet-window-buttons-0.9.0-4.fc36
Summary:  Plasma 5 applet to show window buttons in panels
RPMs: applet-window-buttons
Size: 680.52 KiB
Size change:  -7.48 KiB
Changelog:
  * Tue Dec 07 2021 Onuralp Sezer  - 0.9.0-5
  - 00-fix-update-override.patch add into git source for fix build problem 
(#2024145)git 
  - cosmetic fixes

  * Tue Dec 07 2021 Onuralp Sezer  - 0.10.1-1
  - 0.10.1


Package:  cmake-3.22.1-1.fc36
Old package:  cmake-3.22.0-4.fc36
Summary:  Cross-platform make system
RPMs: cmake cmake-data cmake-doc cmake-filesystem cmake-gui 
cmake-rpm-macros
Size: 50.62 MiB
Size change:  83.16 KiB
Changelog:
  * Tue Dec 07 2021 Bj??rn Esser  - 3.22.1-1
  - cmake-3.22.1
Fixes rhbz#2029974


Package:  dovecot-1

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Chris Adams]

Once upon a time, Björn Persson  said:
> Introducing a new security hole is not just a change like any other
> change.

Calling this "introducing a new security hole" is hyperbole and
fear-mongering.

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

Fedora CoreOS Meeting Minutes 2021-12-08

[Dusty Mabe]

Minutes: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-12-08/fedora_coreos_meeting.2021-12-08-16.29.html
Minutes (text): 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-12-08/fedora_coreos_meeting.2021-12-08-16.29.txt
Log: 
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-12-08/fedora_coreos_meeting.2021-12-08-16.29.log.html



#fedora-meeting-1: fedora_coreos_meeting



Meeting started by dustymabe at 16:29:53 UTC. The full logs are
available at
https://meetbot.fedoraproject.org/fedora-meeting-1/2021-12-08/fedora_coreos_meeting.2021-12-08-16.29.log.html
.



Meeting summary
---
* roll call  (dustymabe, 16:29:58)

* Action items from last meeting  (dustymabe, 16:35:34)

* New Package Request: google-authenticator-libpam  (dustymabe,
  16:37:41)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/1037
(dustymabe, 16:37:47)
  * AGREED: We will not add google-authenticator-libpam for now.
Overlaying the package on first-boot is the currently recommended
approach. It should be investigated if SSSD would be able to perform
2FA.  (dustymabe, 17:10:05)

* Make it easier to change crypto policy  (dustymabe, 17:10:41)
  * LINK: https://github.com/coreos/fedora-coreos-tracker/issues/607
(dustymabe, 17:10:47)
  * LINK:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening
(travier, 17:13:43)
  * LINK:

https://discussion.fedoraproject.org/t/strong-crypto-settings-how-best-to-define-apply/22600/16?u=siosm
(travier, 17:18:53)
  * LINK: https://gitlab.com/redhat-crypto/fedora-crypto-policies
(travier, 17:25:32)
  * AGREED: we will recommend using Butane to set symlinks for now and
approach upstream on whether there are any plans to rewrite the tool
(jlebon, 17:27:41)

* open floor  (dustymabe, 17:28:18)
  * we'll probably skip the community meeting on 12/22 and 12/29 for the
holidays.   (dustymabe, 17:29:04)
  * LINK:

https://github.com/coreos/fedora-coreos-pipeline/blob/main/jobs/kola-kubernetes.Jenkinsfile
(jlebon, 17:29:07)
  * I just learned you can actually make API calls and get an s390x
cloud instance (with /dev/kvm) in IBM Cloud  (dustymabe, 17:31:02)
  * LINK:

https://cloud.ibm.com/docs/vpc?topic=vpc-profiles&interface=ui#balanced-s390x-profiles
(dustymabe, 17:31:55)

Meeting ended at 17:35:06 UTC.




Action Items






Action Items, by person
---
* **UNASSIGNED**
  * (none)




People Present (lines said)
---
* dustymabe (106)
* travier (43)
* jaimelm (37)
* zodbot (27)
* jlebon (25)
* jdoss (19)
* lucab (15)
* nemric (11)
* travier[m] (7)
* lorbus (5)
* saqali_ (3)
* miabbott (2)
* copperi[m] (2)
* ravanelli (1)
* aaradhak (1)
* jmarrero (1)
* Saffronique (0)
* saqali (0)




Generated by `MeetBot`_ 0.4

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

Re: Why CVEs are being filed for EPEL?

[Kevin Fenzi]

On Tue, Dec 07, 2021 at 02:13:46PM +0100, Ondřej Holý wrote:
> Hi all,
> 
> do you have any idea why CVE bugs are being filed for Fedora EPEL
> product in the case of the freerdp component
> (https://src.fedoraproject.org/rpms/freerdp) when there aren't any
> builds for epel7, or epel8? What needs to be done to avoid that, or is
> this a normal approach for other components as well? Should I close
> them as WONTFIX, or what is the expected workflow here?

Huh. Weird. 

I guess I'd say slow them WONTFIX and also mail whoever opened them
asking why there were epel bugs filed? Or you could mail secalert AT
redhat.com and ask them? I would expect no epel bugs in cases where
there are no epel branches. 

kevin


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

Automatic rawhide update did not contain changelog in description nor bugzilla link

[Miro Hrončok]

Hello, in this update:

https://bodhi.fedoraproject.org/updates/FEDORA-2021-4a21ac4839

I would have expected the update description to contain the changelog entry:

* Tue Dec 07 2021 Miro Hrončok  - 206-1
- brp-mangle-shebangs: also mangle shebangs of JavaScript executables
- Fixes: rhbz#1998924

And the bugzilla number (1998924) to be assigned and the bugzilla closed.

Neither happened.

What did I miss? Is this a bug of Bodhi, or of the automation, or my user error?

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Chris Murphy]

On Wed, Dec 8, 2021 at 7:52 AM Lennart Poettering  wrote:
>
> On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
>
> > Latest systemd versions have been getting some support for the low-level
> > parts, i.e. the low-level encrypted-secret storage. But we're missing the
> > upper parts, i.e. how to actually use and update the passwords. I didn't
> > even mention this, because we don't have a comprehensive story yet.
> > I think it'd be necessary to write some pam module and/or authentication
> > helper from scratch. It's probably not too much work, but nobody has
> > signed up to do this.
>
> So here's what I'd suggest: let's define a group (my suggestion: let's
> repurpose "wheel" for that) that has the effect that the passwords of
> any user in it are also accepted as password for the root user,
> implicitly. We'd have to add some small infra to collect these
> passwords, and encrypt/sign them with TPM2, then propagate to the ESP
> or to some EFI var or so, so that they can be honoured already in the
> initrd.

I'm skeptical of any TPM2 dependency because systems still do not come
with them, in particular the significant minority of systems that are
not part of the "made for Windows" marketing program that compels
manufacturers to follow the Windows Hardware Compatibility Program.
And yes you can install Windows 11 without a TPM, it just won't be
preinstalled, and that make/model doesn't qualify for whatever Windows
marketing programs OEM's get for having certified hardware. That's
aside from the fact there's TPM 2.0 in hardware today that the kernel
doesn't support and likely won't ever support.


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

Schedule for Thursday's FPC Meeting (2021-12-09 17:00 UTC)

[James Antill]

 Following is the list of topics that will be discussed in the FPC
meeting Thursday at 2021-12-09 17:00 UTC in #fedora-meeting-1 on
irc.libera.chat.

 Local time information (via. uitime):

= Day: Thursday ==
2021-12-09 09:00 PST  US/Pacific
2021-12-09 12:00 EST  --> US/Eastern <--
2021-12-09 17:00 GMT  Europe/London 
2021-12-09 17:00 UTC  UTC   
2021-12-09 18:00 CET  Europe/Berlin 
2021-12-09 18:00 CET  Europe/Paris  
2021-12-09 22:30 IST  Asia/Calcutta 
 New Day: Friday -
2021-12-10 01:00 HKT  Asia/Hong_Kong
2021-12-10 01:00 +08  Asia/Singapore
2021-12-10 02:00 JST  Asia/Tokyo
2021-12-10 03:00 AEST Australia/Brisbane


 Links to all tickets below can be found at: 

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

= Followup Actions =

#topic #pr-814
 * mhroncok
   talk to authors again, having a working example might help a lot

= Followup Issues =

#topic #886 Enable BRP for detecting RPATH 
.fpc 886
https://pagure.io/packaging-committee/issue/886

#topic #907 Which %__foo macros for executables are acceptable? 
.fpc 907
https://pagure.io/packaging-committee/issue/907

#topic #1058 How to handle %lang files in package owned directories? .fpc 1058
https://pagure.io/packaging-committee/issue/1058

#topic #1132 Mark comments as scriplets for Sources, for automation 
.fpc 1132
https://pagure.io/packaging-committee/issue/1132

= Followup Pull Requests =

#topic #pr-814 Add SELinux Independent Policy Guidelines.
https://pagure.io/packaging-committee/pull-request/814

#topic #pr-1045 WIP: Add discussion of macro names beginning with underscores.
https://pagure.io/packaging-committee/pull-request/1045

#topic #pr-1046 Improve separate test suite sourcing instructions 
https://pagure.io/packaging-committee/pull-request/1046

#topic #pr-1071 Overhaul the RPATH section of the guidelines.
https://pagure.io/packaging-committee/pull-request/1071

#topic #pr-1097 Use caret in Obsoletes to simplify
https://pagure.io/packaging-committee/pull-request/1097


= Open Floor = 

 For more complete details, please visit each individual ticket.  The
report of the agenda items can be found at:

https://pagure.io/packaging-committee/issues?status=Open&tags=meeting

 If you would like to add something to this agenda, you can:
  * Reply to this e-mail
  * File a new ticket at: https://pagure.io/packaging-committee
  * E-mail me directly
  * Bring it up at the end of the meeting, during the open floor topic. Note
    that added topics may be deferred until the following meeting.



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

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Alexander Sosedkin]

On Wed, Dec 8, 2021 at 6:10 PM Björn Persson  wrote:
>
> Chris Adams wrote:
> > Once upon a time, Björn Persson  said:
> > > Chris Adams wrote:
> > > > If the admin has done one thing to lock down the system, then they can
> > > > do another (removing the sulogin --force addition).
> > >
> > > How do you propose to ensure that the admin is made aware of the need
> > > to do that?
> >
> > The same way as any change - documentation.
>
> Introducing a new security hole is not just a change like any other
> change.
>
> Sysadmins read documentation to find solutions when they know that they
> have a problem to solve. They rarely read documentation to look for
> problems they don't know about, and they don't regularly re-read every
> document to look for potentially insecure changes.
>
> > > Experienced sysadmins won't just instinctively know that in this new
> > > release of this particular distribution they need to run this special
> > > command to prevent boot problems from granting root access to whoever
> > > can type on the keyboard.
> >
> > It's not a "special command", it's just removing an RPM
>
> Po-tay-to, po-tah-to.
>
> > I don't install a brand new OS and give it to users without checking it
> > out myself
>
> Does "checking it out" include breaking the system in every way you can
> think of, to see whether one of them yields a root shell?
>
> > (and reading at least the release notes).
>
> Do you also read the release notes of all previous releases just in
> case an obscure weakness was introduced in an old release that you
> never used, and has been in place since then?
>
> > This is NOT some new "hole" - out of the box, Fedora already allows
> > someone with console access to get root access (in less convenient, but
> > more confusing, ways).
>
> What you're actually saying is: There is an old hole that we hope
> sysadmins are aware of and know how to close if they need to, and
> therefore it's fine to punch another hole in a hidden place where
> sysadmins won't think to look.

Sorry, but this one is a tiny brick at the entrance into
a gigantic dark scary hole called 'physical access',
which usually just trips someone up.

Yes, I can imagine a convoluted specifically constructed scenario
where it can play the pivotal role in the security of the overall system.
Meaning, yes, if you manually build the entire missing wall around it,
yanking it out would be bad for you, sure.
That still doesn't deter me from arguing this is a bad default
worth flipping with all the fanfare we can get about 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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Chris Murphy]

On Tue, Dec 7, 2021 at 6:28 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Mon, Dec 06, 2021 at 12:33:21PM -0500, Ben Cotton wrote:
> > Fedora defaults to locking the root account, which is needed by
> > single-user mode. This Change uses `sulogin --force` so the password
> > request is bypassed under this circumstance.
>
> I think this is a terrible idea. The problem is real, but this
> solution addresses it in the wrong place. Essentially, you are proposing
> a behaviour of "something is wrong, let's make everything open without
> authentication", which is good for debugging and development, but not
> acceptable for a real system.

Is it terrible enough that CoreOS should revert?
https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b453902315539e4f327481162c4f8


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

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Björn Persson]

Chris Adams wrote:
> Once upon a time, Björn Persson  said:
> > Chris Adams wrote:  
> > > If the admin has done one thing to lock down the system, then they can
> > > do another (removing the sulogin --force addition).  
> > 
> > How do you propose to ensure that the admin is made aware of the need
> > to do that?  
> 
> The same way as any change - documentation.

Introducing a new security hole is not just a change like any other
change.

Sysadmins read documentation to find solutions when they know that they
have a problem to solve. They rarely read documentation to look for
problems they don't know about, and they don't regularly re-read every
document to look for potentially insecure changes.

> > Experienced sysadmins won't just instinctively know that in this new
> > release of this particular distribution they need to run this special
> > command to prevent boot problems from granting root access to whoever
> > can type on the keyboard.  
> 
> It's not a "special command", it's just removing an RPM

Po-tay-to, po-tah-to.

> I don't install a brand new OS and give it to users without checking it
> out myself

Does "checking it out" include breaking the system in every way you can
think of, to see whether one of them yields a root shell?

> (and reading at least the release notes).

Do you also read the release notes of all previous releases just in
case an obscure weakness was introduced in an old release that you
never used, and has been in place since then?

> This is NOT some new "hole" - out of the box, Fedora already allows
> someone with console access to get root access (in less convenient, but
> more confusing, ways).

What you're actually saying is: There is an old hole that we hope
sysadmins are aware of and know how to close if they need to, and
therefore it's fine to punch another hole in a hidden place where
sysadmins won't think to look.

Björn Persson


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

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Alexander Bokovoy]

On ke, 08 joulu 2021, Matthew Miller wrote:

On Wed, Dec 08, 2021 at 01:50:47PM +0100, Lennart Poettering wrote:

So here's what I'd suggest: let's define a group (my suggestion: let's
repurpose "wheel" for that) that has the effect that the passwords of
any user in it are also accepted as password for the root user,


My working real-world security knowledge is dangerously out of date so I will
defer to others on the proposal itself, but: yes, we already treat wheel
membership as "able to escalate to root", and it seems sane to reuse.


Since we have group merging in effect in glibc, please do not treat a
user present in wheel group but missing in /etc/shadow as something
extra-ordinary. It is a normal situation when you have users in the
centralized identity store like FreeIPA or Samba AD.


--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Matthew Miller]

On Wed, Dec 08, 2021 at 01:50:47PM +0100, Lennart Poettering wrote:
> So here's what I'd suggest: let's define a group (my suggestion: let's
> repurpose "wheel" for that) that has the effect that the passwords of
> any user in it are also accepted as password for the root user,

My working real-world security knowledge is dangerously out of date so I will
defer to others on the proposal itself, but: yes, we already treat wheel
membership as "able to escalate to root", and it seems sane to reuse.

-- 
Matthew Miller

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

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Lennart Poettering]

On Di, 07.12.21 15:39, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> Latest systemd versions have been getting some support for the low-level
> parts, i.e. the low-level encrypted-secret storage. But we're missing the
> upper parts, i.e. how to actually use and update the passwords. I didn't
> even mention this, because we don't have a comprehensive story yet.
> I think it'd be necessary to write some pam module and/or authentication
> helper from scratch. It's probably not too much work, but nobody has
> signed up to do this.

So here's what I'd suggest: let's define a group (my suggestion: let's
repurpose "wheel" for that) that has the effect that the passwords of
any user in it are also accepted as password for the root user,
implicitly. We'd have to add some small infra to collect these
passwords, and encrypt/sign them with TPM2, then propagate to the ESP
or to some EFI var or so, so that they can be honoured already in the
initrd.

With such a mechanism we would have quite nice semantics: if a user is
designated to have admin privs, then that's sufficient to be able to
log into the root account, no further manual work necessary, and it
applies to the whole runtime of the OS: from initrd to regular system,
to sudo.

Lennart

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

Re: Incomprehensible rpmlint error messages

[Zbigniew Jędrzejewski-Szmek]

On Wed, Dec 08, 2021 at 10:41:31AM +0100, Stephan Bergmann wrote:
> On 08/12/2021 09:33, Dan Horák wrote:
> >On Wed, 8 Dec 2021 08:32:10 +0100
> >>>zxing-cpp.x86_64: E: shlib-policy-name-error 1
> >>>zxing-cpp.x86_64: E: invalid-ldconfig-symlink /usr/lib64/libZXing.so.1.2.0 
> >>>libZXing.so.1.2.0
> >>>=== 1 packages and 0 specfiles checked; 2 errors, 0 
> >>>warnings, 2 badness; has taken 2.5 s ===
> >
> >[dan@t460 ~]$ rpmlint -I shlib-policy-name-error
> >shlib-policy-name-error:
> >
> >so yes, this needs further explanation :-)
> 
> Ah, rpmlint-2.1.0-5.fc35.noarch apparently has some -e option instead of an
> -I option now (it doesn't appear to have a man page, though):
> 
> >$ rpmlint -e shlib-policy-name-error
> >shlib-policy-name-error:
> >The package contains shared library but is not named after its SONAME.
> 
> So the proposed package would presumably better be named libZXing rather
> than zxing-cpp.

The package could be also called just 'zxing' if we are expect that the
original non-c++ project will never be imported into fedora. It doesn't
really matter, 'zxing-cpp' matches the upstream name and is just fine.
Whatever you do, please don't add an uppercase letter in the package name ;)

Sometimes rpmlint output should just be ignored, and this seems to be
one of those cases.

> >[dan@t460 ~]$ rpmlint -I invalid-ldconfig-symlink
> >invalid-ldconfig-symlink:
> >The symbolic link references the wrong file. It should reference the
> >shared library.
> 
> ...which still leaves it unclear which symbolic link is allegedly wrong,
> because the libraries and symlinks contained in the rpm look just fine:
> 
> >$ ls -l usr/lib64/
> >total 1204
> >lrwxrwxrwx. 1 sbergman sbergman  17 Dec  7 16:26 libZXing.so.1 -> 
> >libZXing.so.1.2.0
> >-rwxr-xr-x. 1 sbergman sbergman 1229720 Dec  7 16:26 libZXing.so.1.2.0

Yeah, it looks fine to me too.

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

Fedora-Cloud-34-20211208.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-34-20211207.0):

ID: 1080876 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1080876
ID: 1080884 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1080884

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Incomprehensible rpmlint error messages

[Stephan Bergmann]

On 08/12/2021 09:33, Dan Horák wrote:

On Wed, 8 Dec 2021 08:32:10 +0100

zxing-cpp.x86_64: E: shlib-policy-name-error 1
zxing-cpp.x86_64: E: invalid-ldconfig-symlink /usr/lib64/libZXing.so.1.2.0 
libZXing.so.1.2.0
=== 1 packages and 0 specfiles checked; 2 errors, 0 warnings, 2 
badness; has taken 2.5 s ===


[dan@t460 ~]$ rpmlint -I shlib-policy-name-error
shlib-policy-name-error:

so yes, this needs further explanation :-)


Ah, rpmlint-2.1.0-5.fc35.noarch apparently has some -e option instead of 
an -I option now (it doesn't appear to have a man page, though):



$ rpmlint -e shlib-policy-name-error
shlib-policy-name-error:
The package contains shared library but is not named after its SONAME.


So the proposed package would presumably better be named libZXing rather 
than zxing-cpp.



[dan@t460 ~]$ rpmlint -I invalid-ldconfig-symlink
invalid-ldconfig-symlink:
The symbolic link references the wrong file. It should reference the
shared library.


...which still leaves it unclear which symbolic link is allegedly wrong, 
because the libraries and symlinks contained in the rpm look just fine:



$ ls -l usr/lib64/
total 1204
lrwxrwxrwx. 1 sbergman sbergman  17 Dec  7 16:26 libZXing.so.1 -> 
libZXing.so.1.2.0
-rwxr-xr-x. 1 sbergman sbergman 1229720 Dec  7 16:26 libZXing.so.1.2.0



This is from rpmlint 1.11 (F-34), perhaps there is a newer version.

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

Fedora-Cloud-35-20211208.0 compose check report

[Fedora compose checker]

No missing expected images.

Soft failed openQA tests: 1/8 (x86_64), 1/8 (aarch64)
(Tests completed, but using a workaround for a known bug)

Old soft failures (same test soft failed in Fedora-Cloud-35-20211207.0):

ID: 1080685 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/1080685
ID: 1080693 Test: aarch64 Cloud_Base-qcow2-qcow2 cloud_autocloud@uefi
URL: https://openqa.fedoraproject.org/tests/1080693

Passed openQA tests: 7/8 (x86_64), 7/8 (aarch64)
-- 
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: Incomprehensible rpmlint error messages

[Dan Horák]

On Wed, 8 Dec 2021 08:32:10 +0100
Stephan Bergmann  wrote:

> Trying to review  
> "Review Request: zxing-cpp - C++ version of ZXing ("Zebra Crossing") 
> barcode scanning library" on Fedora 35, `fedora-review -b 2029219` 
> produces a 2029219-zxing-cpp/review.txt that states
> 
> > Rpmlint
> > ---
> > Cannot parse rpmlint output:  
> 
> (with no further information), and a manual `rpmlint 
> 2029219-zxing-cpp/results/zxing-cpp-1.2.0-1.fc36.x86_64.rpm` fails with
> 
> > == rpmlint session starts 
> > ==
> > rpmlint: 2.1.0
> > configuration:
> > /usr/lib/python3.10/site-packages/rpmlint/configdefaults.toml
> > /etc/xdg/rpmlint/fedora.toml
> > /etc/xdg/rpmlint/licenses.toml
> > /etc/xdg/rpmlint/scoring.toml
> > /etc/xdg/rpmlint/users-groups.toml
> > /etc/xdg/rpmlint/warn-on-functions.toml
> > checks: 31, packages: 1
> > 
> > zxing-cpp.x86_64: E: shlib-policy-name-error 1
> > zxing-cpp.x86_64: E: invalid-ldconfig-symlink /usr/lib64/libZXing.so.1.2.0 
> > libZXing.so.1.2.0
> > === 1 packages and 0 specfiles checked; 2 errors, 0 
> > warnings, 2 badness; has taken 2.5 s ===  
> 
> and I don't understand what either the shlib-policy-name-error nor the 
> invalid-ldconfig-symlink errors are actually about, and can't find any 
> documentation.

[dan@t460 ~]$ rpmlint -I shlib-policy-name-error
shlib-policy-name-error:

so yes, this needs further explanation :-)

[dan@t460 ~]$ rpmlint -I invalid-ldconfig-symlink
invalid-ldconfig-symlink:
The symbolic link references the wrong file. It should reference the
shared library.

This is from rpmlint 1.11 (F-34), perhaps there is a newer version.


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

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Vitaly Zaitsev via devel]

On 07/12/2021 23:01, przemek klosowski via devel wrote:
I am not sure what would be appropriate for single-user systems: some 
sort of install-time rescue passphrase [1] perhaps, that the user would 
write down and safely store [2]?


This will be a potential backdoor.

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

Re: F36 Change: Make Rescue Mode Work With Locked Root (System-Wide Change proposal)

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 07, 2021 at 05:01:50PM -0500, przemek klosowski via devel wrote:
> On 12/7/21 10:39, Zbigniew Jędrzejewski-Szmek wrote:
> 
> >>>  If available, use
> >>>the TPM2 to additionally tie the password to local hardware. If the
> >>>user is removed, also remove that password from that storage.
> >>>
> >>>During boot, if it is necessary to authenticate before the root file
> >>>system has been mounted, allow admin users to log in using the credentials
> >>>that were stored previously.
> >>Is this being worked on? Do you have any references?
> >Latest systemd versions have been getting some support for the low-level
> >parts, i.e. the low-level encrypted-secret storage. But we're missing the
> >upper parts, i.e. how to actually use and update the passwords. I didn't
> >even mention this, because we don't have a comprehensive story yet.
> 
> A scenario that wasn't mentioned here yet is using a disk from a failed
> system: either moving it to another system, or even simply accessing the
> data. If the credentials (including the LUKS encryption key/password) are
> protected by TPM2, it may effectively prevent any further access. It would
> be useful if any such new scheme avoided that.

The recovery password is necessary for encrypted data. For a user account,
it could be useful, but is less necessary, because generally you're expected
to simply reset the password if lost.

Generally the idea is that you have a nice reasonable-to-type password that
is protected by the TPM, and in addition a second recovery key that
can be used in case the TPM croaks or the disk is moved.

systemd-cryptenroll and homectl support generation of such recovery keys [3,4].
In comparison to a password it is longer and generated from entropy instead
of entered by the user, so brute-force attacks are not a concern. It is
supposed to be written down or saved somewhere when initially creating
the encrypted storage.

> In enterprise system, there usually is a backup decryption key, accessible
> to the enterprise admins. I am not sure what would be appropriate for
> single-user systems: some sort of install-time rescue passphrase [1]
> perhaps, that the user would write down and safely store [2]?
> 
> [1] https://xkcd.com/936/
> 
> [2] conveniently stored next to the rubber hose so that the attackers could
> forgo its use and type the rescue passphrase themselves.
> https://xkcd.com/538/
That's a classic ;)

[3] https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html
[4] https://www.freedesktop.org/software/systemd/man/homectl.html

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

Re: rpm bug for multiple README.md or LICENSE.md in EPEL 8 and Fedora

[Panu Matilainen]

On 12/7/21 16:18, Nico Kadel-Garcia wrote:

On Tue, Dec 7, 2021 at 5:46 AM Panu Matilainen  wrote:


On 12/5/21 05:07, Nico Kadel-Garcia wrote:

I've been trying to bundle the current ansible-5.0.1 release as an RPM
for Fedora and EPEL use. Leaving aside the peculiar decisions to
replace the pypi.org "ansible" tarball with a tarball of roughly 150
modules from the "ansiblee-collections" repos, and moving the actual
ansible software to a distinct python tarball called "ansible-core"
without changing the source repo or the actual critical installed
python modules, the new "ansible" has more than 300 files called
"README.md" and more than 100 files called "LICENSE.md".

This breaks building RPMs for EPEL 8 or Fedora, because the '%doc' and
'%license' macros strip off the subdirectories of the files and
install them directly at the top of the docdir.

Basicely these only generate one file:

 %doc README.md
 %doc dir1/README.md
 %doc dir2/README.md

 %license LICENSE.md
  %license dir1/LICENSE
  %license dir2/LICENSE.md

When compiled, these would only produce:

/usr/share/doc/package-%{fersion}/README.md
/usr/share/doc/package-%{fersion}/LICENSE.md

RHEL 7 didn't have this problem. I'm not sure if other folks have
noticed this for tools that are built with multiple internal tarballs.
The new "ansible" tarball is fairly unique ints authors insistance on
putting more than one hundred distinct third party packages in the
same master tarball. But for now, this is going to cause a license and
documentation problem in packaging it due to an "optimization" of
stripping out the directory names of document files and licenses.

Does anyone know a decent workaround, or a specfile setting to disable
this filename stripping and restore the RHEL 7 behavior?


There were changes in how %doc is handled around rpm 4.13 (whereas
RHEL-7 has 4.11), maybe there's a regression that nobody noticed (or
complained about) until now. The use-case there seems quite reasonable
to me.

File a bug on rpm (preferably upstream ticket) to have it looked at.

 - Panu -


I've submitted one, at https://bugzilla.redhat.com/show_bug.cgi?id=2029877 .

It seems that the problem existed as well with earlier versions of
rpmbuild, say on RHEL 7, but the warning messages about "files listed
twice" weren't generated. And various slightly differently named
README.md and LICENSE.md files make it not as obvious as one might
expect.


Okay, but since it happens on RHEL 7 too then there's no regression. I 
thought the leading directories were always stripped but given your 
strong statement about RHEL 7 not having this issue I thought maybe I'm 
missing something.


The current behavior is good for other use-cases and we can't go just 
changing it, but this is a totally legit (and common, I think) use-case 
so maybe we can come up with something to optionally not strip leading 
directories.


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