date:20220131

Re: CVE-2021-4034: why is pkexec still a thing?

2022-01-31 Thread Miroslav Suchý

Dne 31. 01. 22 v 20:39 Adam Williamson napsal(a):

but very soon I discovered that documentation of PolicyKit is nearly
non-existent. At least, it is not sufficient to do
the migration. After reading the code I found that it is likely missing
functionality of consolehelper.

I had a discussion with maintainer of PolicyKit and we both come conclusion
that PolicyKit stopped in the middle of
nowhere and for me and Mock is better to stay with consolehelper.

Does the situation have changed?

I don't know. I can't tell from the above what documentation or
functionality you're missing, and that info doesn't seem to be in the
ticket or bug you linked either (except a very vague mention of needing
"to handle ENV".) I don't know when your conversations and research
took place, so it's hard to say what's changed since.

polkit's maintainer has changed twice (I think) since the time this
feature was introduced, it's currently Jan Rybar. The current polkit
documentation is at
https://www.freedesktop.org/software/polkit/docs/latest/ .

The documentation seems to be slightly better, but after reading it I still
have several questions:

* what is the preferred way to run python scripts? Is it using pkexec in shebang (seems to be discouraged in this
thread) or using this technique?:

https://stackoverflow.com/questions/32332128/how-to-use-polkit-with-python-to-run-systemd-d-bus-commands-from-non-root-user

* what is the best way to mimic KEEP_ENV_VARS from `userhelper(8)`?

Miroslav
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: CVE-2021-4034: why is pkexec still a thing?

2022-01-31 Thread Demi Marie Obenour

On 1/31/22 21:15, Neal Gompa wrote:
> On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb  wrote:
>>
>> Hello Mirek,
>>
>> This is the most constructive reply I've seen in this thread.
>>
>> On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote:
 But doesn't satisfy our security requirements. If the kernel dbus project
 had been successful, then Linux would have had a rock solid basis to
 allow impersonation which would satisfy the security requirements and
 allow the desktop actually go through a common criteria certification if
 any one ever  wanted to do that. But as it stands, anything created by
 IPC is missing the necessary security context.
>>>
>>> I mean, yes. I read that as not a reason to stick with set-uid, but as a
>>> reason to make that a priority, and drive the investment and the cultural
>>> change; otherwise Linux security is just going to keep falling behind. OTOH
>>> with the consolehelper history and a lot of similar examples, I don’t know
>>> how to do any of that (make it a priority, drive the investment, drive the
>>> cultural change).
>>
>> Linux needs a first class impersonation mechanism. This would be where the
>> kernel bestows upon a process, certain attributes from another process. Both
>> sides should agree so that no toke kidnapping is possible or forcing
>> credentials on an unsuspecting process. With something like this, we can
>> start to solve the security problems caused by IPC instantiation. I was
>> really hoping kernel dbus was successful way back when.
>>
>>
 And access decisions do not go through the audit system.
>>>
>>> For polkit, that would be… a 20-line patch?
>>
>> Probably a little more. The auditing would need to be selective and by admin
>> control. Meaning, the admin may decide that they want auditing of one
>> application's permission grants and not the other.
>>
>>> Sure, the invoking user’s configuration can be trusted only to the extent a
>>> D-Bus server provides it correctly to Polkit, making the D-Bus servers a
>>> part of the trusted codebase. Still, that would be pretty valuable at least
>>> until the first successful exploit.
>>
>> I was hoping with kernel dbus, polkit would have examined the connections
>> itself and asked the kernel for veracity of the request. I really wished that
>> was given another try and everyone agreed on why it was necessary so that it
>> could be articulated well to the people that have to say yes/no to the patch.
> 
> An in-kernel first-class IPC would make tremendous inroads in Linux
> security, but who is going to drive that anymore? Bus1
> (https://bus1.org/) hasn't been touched since 2019. Bus1 had an RFC in
> 2016 on LKML[1] and that's it.
> 
> We *could* use Binder, but there's a general lethargy around trying to
> leverage stuff from the Android/ChromeOS ecosystem to benefit regular
> Linux systems. We *do* have it enabled in our kernel, but that's
> mainly for the eventual support of Waydroid in Fedora Mobile.

Why not use Binder?  It is *the* in-tree solution for fast IPC.

-- 
Sincerely,
Demi Marie Obenour
she/her/hers

OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key


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

Re: CVE-2021-4034: why is pkexec still a thing?

2022-01-31 Thread Neal Gompa

On Mon, Jan 31, 2022 at 8:19 PM Steve Grubb  wrote:
>
> Hello Mirek,
>
> This is the most constructive reply I've seen in this thread.
>
> On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote:
> > > But doesn't satisfy our security requirements. If the kernel dbus project
> > > had been successful, then Linux would have had a rock solid basis to
> > > allow impersonation which would satisfy the security requirements and
> > > allow the desktop actually go through a common criteria certification if
> > > any one ever  wanted to do that. But as it stands, anything created by
> > > IPC is missing the necessary security context.
> >
> > I mean, yes. I read that as not a reason to stick with set-uid, but as a
> > reason to make that a priority, and drive the investment and the cultural
> > change; otherwise Linux security is just going to keep falling behind. OTOH
> > with the consolehelper history and a lot of similar examples, I don’t know
> > how to do any of that (make it a priority, drive the investment, drive the
> > cultural change).
>
> Linux needs a first class impersonation mechanism. This would be where the
> kernel bestows upon a process, certain attributes from another process. Both
> sides should agree so that no toke kidnapping is possible or forcing
> credentials on an unsuspecting process. With something like this, we can
> start to solve the security problems caused by IPC instantiation. I was
> really hoping kernel dbus was successful way back when.
>
>
> > > And access decisions do not go through the audit system.
> >
> > For polkit, that would be… a 20-line patch?
>
> Probably a little more. The auditing would need to be selective and by admin
> control. Meaning, the admin may decide that they want auditing of one
> application's permission grants and not the other.
>
> > Sure, the invoking user’s configuration can be trusted only to the extent a
> > D-Bus server provides it correctly to Polkit, making the D-Bus servers a
> > part of the trusted codebase. Still, that would be pretty valuable at least
> > until the first successful exploit.
>
> I was hoping with kernel dbus, polkit would have examined the connections
> itself and asked the kernel for veracity of the request. I really wished that
> was given another try and everyone agreed on why it was necessary so that it
> could be articulated well to the people that have to say yes/no to the patch.

An in-kernel first-class IPC would make tremendous inroads in Linux
security, but who is going to drive that anymore? Bus1
(https://bus1.org/) hasn't been touched since 2019. Bus1 had an RFC in
2016 on LKML[1] and that's it.

We *could* use Binder, but there's a general lethargy around trying to
leverage stuff from the Android/ChromeOS ecosystem to benefit regular
Linux systems. We *do* have it enabled in our kernel, but that's
mainly for the eventual support of Waydroid in Fedora Mobile.

So what should we do? I don't know. It seems the answer everyone else
offers is "give up". I don't like that answer, but what else can we
do?

[1]: https://lkml.org/lkml/2016/10/26/963



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2046600] perl-App-cpanminus-1.7045 is available

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



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

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2046600
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

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

2022-01-31 Thread updates

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
   4  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-6395a45cb3   
perl-Image-ExifTool-12.38-1.el7
   1  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-4069001f10   
miniupnpc-2.0-3.el7


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

epel-rpm-macros-7-34
nodejs-16.13.2-5.el7
php-phpseclib-2.0.36-1.el7
tcpreplay-4.4.0-1.el7

Details about builds:



 epel-rpm-macros-7-34 (FEDORA-EPEL-2022-66d92f182c)
 Extra Packages for Enterprise Linux RPM macros

Update Information:

Drop the `%{nodejs_arches}` override. The RHEL 7 version has been fixed.

ChangeLog:

* Mon Jan 31 2022 Stephen Gallagher  - 7-34
- Drop nodejs_arches override. RHEL now provides all of the arches.




 nodejs-16.13.2-5.el7 (FEDORA-EPEL-2022-b07aca13c8)
 JavaScript runtime

Update Information:

Lighten some dependencies to make it easier to minimize container footprint

ChangeLog:

* Mon Jan 31 2022 Stephen Gallagher  - 1:16.13.2-3
- Tweak some dependencies on EPEL 7 (bz2048589)
- Add (Provides: bundled(zlib))

References:

  [ 1 ] Bug #2048589 - Update version of nodejs requires -devel and -docs and 
can't be removed without all of nodejs.
https://bugzilla.redhat.com/show_bug.cgi?id=2048589




 php-phpseclib-2.0.36-1.el7 (FEDORA-EPEL-2022-f414e23b48)
 PHP Secure Communications Library

Update Information:

**Version 2.0.36** - 2022-01-30  - SSH2: make login() return false if no valid
auth methods are found (#1744) - SFTP: fix chgrp() for version < 4 (#1730) -
Crypt/Base: add OFB8 as a new mode (phpseclib/mcrypt_compat#33) - RSA &
BigInteger: check phpinfo() available before using it (#1726)

ChangeLog:

* Mon Jan 31 2022 Remi Collet  - 2.0.36-1
- update to 2.0.36




 tcpreplay-4.4.0-1.el7 (FEDORA-EPEL-2022-d421b6dfec)
 Replay captured network traffic

Update Information:

Tcpreplay suite 4.4.0 changes:   - Update strlcpy.c and strlcat.c by @guijan in
#656  - 4.3.4 by @fklassen in #636  - Apply #616 fix to flows.c, fix #665 by
@dumprop in #666  - Bug #670: update Travis CI to focal by @fklassen in #672  -
Bug #669: LINUX installed netmap auto detection by @fklassen in #673  - Feature
#626 - Support for Q-in-Q VLAN tags by @fklassen in #675  - Bug #677
skipbroadcast by @fklassen in #678  - Bug #689: add security policy document by
@fklassen in #691  - Directories of pcaps as arguments by @halver94 in #682  -
PR #682 stage PR from @halver94 by @fklassen in #692  - Bug #679 fix PPS calc
for long-running sessions by @fklassen in #693  - Bug #668 Improve SDK selection
by @fklassen in #694  - Bug #696 fix directory include feature by @fklassen in
#697  - Bug #695 mac os tests fail by @fklassen in #698  - Bug #674 - Revert
"send_packet: Avoid clock drift by using time since first packet" by @fklassen
in #699  - Feature #563 mac update on multicast by @fklassen in #700

ChangeLog:

* Mon Jan 31 2022 Bojan Smojver  - 4.4.0-1
- bump up to 4.4.0
* Sat Jan 22 2022 Fedora Release Engineering  - 
4.3.4-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_36_Mass_Rebuild
* Fri Jul 23 2021 Fedora Release Engineering  - 
4.3.4-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_35_Mass_Rebuild


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

[Bug 2043397] perl-Email-Abstract for EPEL9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-93d3b108e8 has been pushed to the Fedora EPEL 9 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-93d3b108e8

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2043397
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: CVE-2021-4034: why is pkexec still a thing?

2022-01-31 Thread Andrew Lutomirski

On Mon, Jan 31, 2022 at 5:24 PM Steve Grubb  wrote:
>
> Hello Mirek,
>
> This is the most constructive reply I've seen in this thread.
>
> On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote:
> > > But doesn't satisfy our security requirements. If the kernel dbus project
> > > had been successful, then Linux would have had a rock solid basis to
> > > allow impersonation which would satisfy the security requirements and
> > > allow the desktop actually go through a common criteria certification if
> > > any one ever  wanted to do that. But as it stands, anything created by
> > > IPC is missing the necessary security context.
> >
> > I mean, yes. I read that as not a reason to stick with set-uid, but as a
> > reason to make that a priority, and drive the investment and the cultural
> > change; otherwise Linux security is just going to keep falling behind. OTOH
> > with the consolehelper history and a lot of similar examples, I don’t know
> > how to do any of that (make it a priority, drive the investment, drive the
> > cultural change).
>
> Linux needs a first class impersonation mechanism. This would be where the
> kernel bestows upon a process, certain attributes from another process. Both
> sides should agree so that no toke kidnapping is possible or forcing
> credentials on an unsuspecting process. With something like this, we can
> start to solve the security problems caused by IPC instantiation. I was
> really hoping kernel dbus was successful way back when.
>

Windows has a first class impersonation mechanism, and it's really
quite complicated and far from rock solid.  I don't think Linux should
go that direction.

But I'm a bit baffled by the assertion that anything created by IPC is
missing the necessary security context.  The entire world of
distributed systems is missing this security context.  When I issue
REST request or a gRPC request or really any network request at all, I
have precisely whatever context I specifically authenticate with for
that call.  And, other than the fact that most systems use rather weak
authentication systems (mostly bearer tokens), this is *good* -- it
means that the credential being presented is, by construction,
intentional on the part of the presenter.  It also means that
incorrect inferences aren't drawn.  For example, in a world where an
entire security context comes along with a request, if process A asks
database server B to write a row *over a network*, and B asks the
filesystem (C) to do the write, we don't magically attribute more of
B's context than we should to the write.

I would love to see a nice security model for IPC in the Linux kernel,
but I haven't seen a credible proposal.  This problem is *hard*.

As for setuid, I'm strongly of the opinion that setuid was and remains
a mistake.  Executing a process should never add privileges.
Replacing sudo, etc well probably requires a mechanism by which a
process can allow a daemon to either create children of that process
or replace that process (in the exec sense).  The SELinux label to
apply to the newly created process should be the daemon's decision --
it's far from obvious that a sudo'd program should inherit sudo's
caller's label.

--Andy

>
> > > And access decisions do not go through the audit system.
> >
> > For polkit, that would be… a 20-line patch?
>
> Probably a little more. The auditing would need to be selective and by admin
> control. Meaning, the admin may decide that they want auditing of one
> application's permission grants and not the other.
>
> > Sure, the invoking user’s configuration can be trusted only to the extent a
> > D-Bus server provides it correctly to Polkit, making the D-Bus servers a
> > part of the trusted codebase. Still, that would be pretty valuable at least
> > until the first successful exploit.
>
> I was hoping with kernel dbus, polkit would have examined the connections
> itself and asked the kernel for veracity of the request. I really wished that
> was given another try and everyone agreed on why it was necessary so that it
> could be articulated well to the people that have to say yes/no to the patch.
>
> -Steve
>
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

[Bug 2038239] Please branch and build perl-Test-Pod-LinkCheck for EPEL-9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2022-02-01 01:23:31



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-5473bf1bfa has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2038239
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2041077] Please build perl-Net-XMPP for EPEL 9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-Net-XMPP-1.05-20.el9
Last Closed||2022-02-01 01:23:48



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-351a4e6303 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2041077
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2038059] perl-CGI-Compile for EPEL 9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-CGI-Compile-0.25-6.el9
 Resolution|--- |ERRATA
Last Closed||2022-02-01 01:24:04



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-fc8d1b9866 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2038059
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2033601] Add perl-Geo-Distance to EPEL 9

2022-01-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2033601
Bug 2033601 depends on bug 2033614, which changed state.

Bug 2033614 Summary: Add perl-GIS-Distance to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2033614

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2033601
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2042872] Please branch and build perl-bareword-filehandles for EPEL 9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2022-02-01 01:23:57



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-0b67734bdf has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2042872
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2031812] perl-Plack for EPEL 9

2022-01-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2031812
Bug 2031812 depends on bug 2038059, which changed state.

Bug 2038059 Summary: perl-CGI-Compile for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2038059

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2031812
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2032428] perl-RDF-Trine for EPEL 9

2022-01-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2032428
Bug 2032428 depends on bug 2033630, which changed state.

Bug 2033630 Summary: Add perl-IRI for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2033630

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2032428
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2032426] perl-RDF-Query for EPEL 9

2022-01-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2032426
Bug 2032426 depends on bug 2033601, which changed state.

Bug 2033601 Summary: Add perl-Geo-Distance to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2033601

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2032426
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2033601] Add perl-Geo-Distance to EPEL 9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2022-02-01 01:23:33



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-dc78f35285 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2033601
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2042871] Please branch and build perl-multidimensional for EPEL 9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2022-02-01 01:23:55



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-5ef60c45ee has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2042871
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2041248] perl-XML-Stream for EPEL 9

2022-01-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2041248
Bug 2041248 depends on bug 2042595, which changed state.

Bug 2042595 Summary: perl-HTTP-ProxyAutoConfig for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2042595

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2041248
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2033630] Add perl-IRI for EPEL 9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
Last Closed||2022-02-01 01:23:36



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-56faadb7a0 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2033630
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2042595] perl-HTTP-ProxyAutoConfig for EPEL 9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version||perl-HTTP-ProxyAutoConfig-0
   ||.3-27.el9
 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2022-02-01 01:23:45



--- Comment #4 from Fedora Update System  ---
FEDORA-EPEL-2022-880f8c4258 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2042595
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2032428] perl-RDF-Trine for EPEL 9

2022-01-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2032428
Bug 2032428 depends on bug 2038180, which changed state.

Bug 2038180 Summary: Add perl-XML-CommonNS to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2038180

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2032428
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2038180] Add perl-XML-CommonNS to EPEL 9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Resolution|--- |ERRATA
 Status|ON_QA   |CLOSED
Last Closed||2022-02-01 01:23:22



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-f1f30a32a9 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2038180
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2041077] Please build perl-Net-XMPP for EPEL 9

2022-01-31 Thread bugzilla

https://bugzilla.redhat.com/show_bug.cgi?id=2041077
Bug 2041077 depends on bug 2041247, which changed state.

Bug 2041247 Summary: perl-LWP-Online for EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2041247

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA




-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2041077
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2041247] perl-LWP-Online for EPEL 9

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-LWP-Online-1.08-32.el9
Last Closed||2022-02-01 01:23:15



--- Comment #5 from Fedora Update System  ---
FEDORA-EPEL-2022-8f91a25c60 has been pushed to the Fedora EPEL 9 stable
repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2041247
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

[Bug 2047875] Please branch and build perl-Socket-MsgHdr for EPEL8

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #7 from Fedora Update System  ---
FEDORA-EPEL-2022-c8324d009f has been pushed to the Fedora EPEL 8 testing
repository.

You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2022-c8324d009f

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


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2047875
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: search among all spec files

2022-01-31 Thread Sérgio Basto

On Tue, 2022-02-01 at 01:03 +0100, Germano Massullo wrote:
> Good day. I have to search gcc-toolset among all Fedora packages specs 
> files, in order to read some example of usage.
> Is that possible? For example cloning the whole git repository.
> 

also you got sourcegraph 
https://sourcegraph.com/search?q=context:global+r:src.fedoraproject.org+file:.*%5C.spec%24+%5ELicense:+MIT=regexp=yes

reference:
https://lists.fedoraproject.org/archives/list/packag...@lists.fedoraproject.org/message/J4I74HDXAX2UWCVEMGUAICEKCMLXW5B3/

--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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

[Bug 2043770] perl-Net-HTTP-6.22 is available

2022-01-31 Thread bugzilla

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
 Resolution|--- |ERRATA
   Fixed In Version||perl-Net-HTTP-6.22-1.fc35
Last Closed||2022-02-01 01:12:04



--- Comment #6 from Fedora Update System  ---
FEDORA-2022-af9f3e8f02 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2043770
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: CVE-2021-4034: why is pkexec still a thing?

2022-01-31 Thread Steve Grubb

Hello Mirek,

This is the most constructive reply I've seen in this thread.

On Monday, January 31, 2022 1:12:50 PM EST Miloslav Trmac wrote:
> > But doesn't satisfy our security requirements. If the kernel dbus project
> > had been successful, then Linux would have had a rock solid basis to
> > allow impersonation which would satisfy the security requirements and
> > allow the desktop actually go through a common criteria certification if
> > any one ever  wanted to do that. But as it stands, anything created by
> > IPC is missing the necessary security context.
> 
> I mean, yes. I read that as not a reason to stick with set-uid, but as a
> reason to make that a priority, and drive the investment and the cultural
> change; otherwise Linux security is just going to keep falling behind. OTOH
> with the consolehelper history and a lot of similar examples, I don’t know
> how to do any of that (make it a priority, drive the investment, drive the
> cultural change).

Linux needs a first class impersonation mechanism. This would be where the 
kernel bestows upon a process, certain attributes from another process. Both 
sides should agree so that no toke kidnapping is possible or forcing 
credentials on an unsuspecting process. With something like this, we can 
start to solve the security problems caused by IPC instantiation. I was 
really hoping kernel dbus was successful way back when.

> > And access decisions do not go through the audit system.
> 
> For polkit, that would be… a 20-line patch? 

Probably a little more. The auditing would need to be selective and by admin 
control. Meaning, the admin may decide that they want auditing of one 
application's permission grants and not the other.

> Sure, the invoking user’s configuration can be trusted only to the extent a
> D-Bus server provides it correctly to Polkit, making the D-Bus servers a
> part of the trusted codebase. Still, that would be pretty valuable at least
> until the first successful exploit.

I was hoping with kernel dbus, polkit would have examined the connections 
itself and asked the kernel for veracity of the request. I really wished that 
was given another try and everyone agreed on why it was necessary so that it 
could be articulated well to the people that have to say yes/no to the patch.

-Steve

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

Schedule for Tuesday's FESCo Meeting (2022-02-01)

2022-01-31 Thread Tom Stellard


Following is the list of topics that will be discussed in the
FESCo meeting Tuesday at 18:00UTC in #fedora-meeting on
irc.libera.chat.

To convert UTC to your local time, take a look at
  http://fedoraproject.org/wiki/UTCHowto

or run:
  date -d '2022-02-01 18:00 UTC'


Links to all issues to be discussed can be found at:
https://pagure.io/fesco/report/meeting_agenda

= Discussed and Voted in the Ticket =

#2737 F36 Change: Ibus-table cangjie default for zh_HK
https://pagure.io/fesco/issue/2737
APPROVED (+6,0,-0)

#2736 F36 Change: Malayalam Default Fonts Update
https://pagure.io/fesco/issue/2736
APPROVED (+5,0,-0)

#2735 F36 Change: New requirements for akmods binary kernel modules for 
Silverblue / Kinoite support
https://pagure.io/fesco/issue/2735
APPROVED (+4,0,-0)

#2733 F36 Change: Django 4.0
https://pagure.io/fesco/issue/2733
APPROVED (+3,0,-0)

#2722 Nonresponsive maintainer: xgl-maint - xgl-maint
https://pagure.io/fesco/issue/2722
APPROVED

#2719 Nonresponsive maintainer: Brian Pepple bpepple
https://pagure.io/fesco/issue/2719
APPROVED

#2716 F36 Change: Keylime subpackaging and agent alternatives
https://pagure.io/fesco/issue/2716
APPROVED (+5,0,-0)

= Discussed and Voted in the previous meeting =
#2732 F36 Change: No ifcfg by default
https://pagure.io/fesco/issue/2732
APPROVED (+8,0,-0)

#2721 F37 Change: DIGLIM
https://pagure.io/fesco/issue/2721
Deferred to F37 (+8, 0, -0)

#2711 F37 Change: Enable fs-verity in RPM
https://pagure.io/fesco/issue/2711
Deferred to F37 (+9, 0, -0)

= New business =

#2741 Change proposal: Authselect: Move State Files to /etc
https://pagure.io/fesco/issue/2741

= Open Floor =

For more complete details, please visit each individual
issue.  The report of the agenda items can be found at
https://pagure.io/fesco/report/meeting_agenda

If you would like to add something to this agenda, you can
reply to this e-mail, file a new issue at
https://pagure.io/fesco, e-mail me directly, or 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

[EPEL-devel] Re: Revisiting policy for limited arch packages?

2022-01-31 Thread Kevin Fenzi

On Mon, Jan 31, 2022 at 06:48:21PM +, Gary Buhrmaster wrote:
> On Mon, Jan 31, 2022 at 4:55 PM Kevin Fenzi  wrote:
> 
> > The limited arch policy we had for epel7 had a number of problems.
> > At first we just said 'rebuild the exact rhel version' and then we
> > switched to 'add a 0 to release so the rhel package always gets
> > installed in favor of it'.
> 
> It (probably?) would not hurt to have the epel
> repos have a higher cost in the repo config
> to discourage choosing the epel package over
> the rhel package (if all things are equal, but
> of course, they are not always equal).
> 
> For some specific cases where I needed to
> build the -devel package in a copr (until or
> unless I can get the -devel packages shipped
> in CRB (or equivalent)) I have manually set
> the cost for the copr repos to be high so that
> for a non -devel install I got the rhel versions.
> I would love to know if there is a better way.
> It all just seems so non-optimal.

Sure, we could do that, but it's far from foolproof. 
Many people make their own repo files, or they might have their own
weight schemes. It also doesn't help any building against things in
koji. 

kevin


signature.asc
Description: PGP signature
___
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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: search among all spec files

2022-01-31 Thread Ben Beasley

Check https://src.fedoraproject.org/lookaside/, specifically 
https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz. This covers 
Rawhide only, of course.

On Mon, Jan 31, 2022, at 7:03 PM, Germano Massullo wrote:
> Good day. I have to search gcc-toolset among all Fedora packages specs 
> files, in order to read some example of usage.
> Is that possible? For example cloning the whole git repository.
> Best regards
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: search among all spec files

2022-01-31 Thread Miro Hrončok


On 01. 02. 22 1:03, Germano Massullo wrote:
Good day. I have to search gcc-toolset among all Fedora packages specs files, 
in order to read some example of usage.

Is that possible? For example cloning the whole git repository.


This tarball contains all Rawhide spec files, updated I believe daily.

https://pkgs.fedoraproject.org/repo/rpm-specs-latest.tar.xz

--
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: search among all spec files

2022-01-31 Thread Kevin Fenzi

On Tue, Feb 01, 2022 at 01:03:22AM +0100, Germano Massullo wrote:
> Good day. I have to search gcc-toolset among all Fedora packages specs
> files, in order to read some example of usage.
> Is that possible? For example cloning the whole git repository.

Well, each package is it's own git repo, there's not a overall one. 

That said, we have a cron that makes a archive of all spec files every
night: 

https://src.fedoraproject.org/lookaside/rpm-specs-latest.tar.xz

you can grab that, unpack it and search it locally?

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

search among all spec files

2022-01-31 Thread Germano Massullo

Good day. I have to search gcc-toolset among all Fedora packages specs 
files, in order to read some example of usage.

Is that possible? For example cloning the whole git repository.
Best regards
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: 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: gcc-12.0.0-0.4.fc36 in rawhide

2022-01-31 Thread Benjamin Beasley

> * Jakub Jelinek:
> 
> 
> I think Kevin has posted a GDB patch for the crash:
> 
>   [PATCH] Fix GDB internal error by using text (instead of data) section 
> offset
>   
> 
> The bug was exposed by the loss of the .data section in libgcc_s,
> presumably caused by the unwinder changes.  The GCC change is fine by
> itself, it's a real GDB bug.
> 
> Thanks,
> Florian

Thanks for the pointer! I did a successful local mock-build of debugbreak with 
the patched RPMs from the scratch build linked in 
https://bugzilla.redhat.com/show_bug.cgi?id=2042664#c4, which confirms I really 
am seeing that particular GDB bug.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: CVE-2021-4034: why is pkexec still a thing?

2022-01-31 Thread Sam Varshavchik


Lennart Poettering writes:


See the discussion around seccomp and NNP. i.e. a new kernel facility
was added precisely to ensure that seccomp cannot be used to run code
that is intended to be run privileged – under security policies in
control by an unprivileged user. i.e. if you can take certain privs
away from code that expects to have them you might be able to trigger
vulnerable codepaths that the developer didn't expect you to be able
to trigger.

But anyway, don't focus so much in cgroups here. There are plenty
other props these days that sudo doesn#t clean up. consider this for


Ok, so where's the track record of potential security exploits, in similar  
kinds of tools, that: 1) leverage any of the resources that you mentioned,  
and 2) but were mitigated, and became ordinary bugs, thanks to the  
vulnerable code being an isolated daemon process, with a clean environment.


In absence of an established track record that demonstrates this, in  
practice, this becomes just a theory. So, I'm not sure that it's clear to me  
-- is this getting argued based on an established track record, with some  
data to look at, the shows – based on some basic metrics – the benefits of  
rewriting suid programs in this manner; or is this just a theoretical  
argument.


Every additional line of code written to architect a privileged process, in  
this new manner, is a potential spot for a new bug to grow.


Rolling out a brand-spanking update, with a new architecture, new  
bootstrapping mechanism, and a new unprivileged process will become a  
Pyrrhic victory a year later, when it turns out that the privileged process  
trusted input from the unprivileged process, as an indirect result of new  
serialization/deserialization code that had to be written. That's where the  
bulk of the work was. And validating the deserialized data structure was  
accidentally overlooked.


Or the new serialization/deserialization code has its own buffer overflows.  
That would be code that didn't exist in the original, monolithic setuid  
executable.




pgp55rJYDskLq.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: conditional require

2022-01-31 Thread Miro Hrončok


On 31. 01. 22 23:51, Steven A. Falco wrote:

On 1/31/22 05:08 PM, Steven A. Falco wrote:

On 1/31/22 04:04 PM, Miro Hrončok wrote:

On 31. 01. 22 21:58, przemek klosowski via devel wrote:
During recent major version update, some files were moved from 
-doc to , and as a result updates of  fail due 
to a file conflict. Manual update of -doc resolves this, of course.


A simple solution would be to declare that 

Required: package-doc >= 6.0.0

but that would force the install of the docs package if it wasn't already 
there.


Is there a way to declare a dependency only if the other package is 
present/installed? Would


Obsoletes: package-doc < 6.0.0

be the right thing to do?


The right thing to do is:

   Conflicts: package-doc < 6.0.0


Ok, so that doesn't do what I'd like.  I definitely added the conflict property:

# rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 6.0.0

But when I try to upgrade just the kicad package without upgrading the docs 
package, I still get:


# dnf update kicad-6.0.1-4.fc35.x86_64.rpm
...
Running transaction test
Error: Transaction test error:
   file /usr/share/doc/kicad/scripts/lib_convert.py from install of 
kicad-1:6.0.1-4.fc35.x86_64 conflicts with file from package 
kicad-doc-1:5.1.12-1.fc35.noarch
   file /usr/share/doc/kicad/scripts/test_kicad_plugin.py from install of 
kicad-1:6.0.1-4.fc35.x86_64 conflicts with file from package 
kicad-doc-1:5.1.12-1.fc35.noarch


So the Conflicts line doesn't actually seem to buy me anything.

I'll try again with the version from Stephen Gallagher (including the epoch) 
and see if that is any better.

The Conflict flag is now set to:

# rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 1:6.0.1-4.fc35


Oh, I did not know the package has an epoch.


And the result is:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm
Last metadata expiration check: 0:40:27 ago on Mon 31 Jan 2022 05:06:19 PM EST.
Dependencies resolved.

  Problem: problem with installed package kicad-doc-1:5.1.12-1.fc35.noarch
   - package kicad-1:6.0.1-4.fc35.x86_64 conflicts with kicad-doc < 
1:6.0.1-4.fc35 provided by kicad-doc-1:5.1.12-1.fc35.noarch
   - cannot install the best update candidate for package 
kicad-1:5.1.12-1.fc35.x86_64
 

  Package  Architecture  Version   
Repository   Size
 


Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
  kicad    x86_64    1:6.0.1-4.fc35
@commandline 90 M


Transaction Summary
 


Skip  1 Package

When I add the '--best --allowerasing' flags, then I get the desired result:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm --best --allowerasing
Last metadata expiration check: 0:43:04 ago on Mon 31 Jan 2022 05:06:19 PM EST.
Dependencies resolved.
 

  Package    Architecture    Version 
Repository Size
 


Upgrading:
  kicad  x86_64  1:6.0.1-4.fc35  
@commandline   90 M

Removing dependent packages:
  kicad-doc  noarch  1:5.1.12-1.fc35 
@updates  111 M


So that looks like the best solution.


What you haven't mentioned is if kicad-doc 1:6.0.x still exists but just with 
fewer files or if it is gone entirely.

If it is gone, you should probably obsolete it.



--
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: CVE-2021-4034: why is pkexec still a thing?

2022-01-31 Thread Sam Varshavchik


Demi Marie Obenour writes:


What would break if sudo was replaced by an IPC service that ran
sudo as if it was setuid root, without it actually being setuid root?
I imagine the hardest part would be TTY handling, as not being able
to Ctrl-C a command launched by sudo is a rather poor user experience.


File descriptors can be sent across filesystem sockets, this can be done.  
Once that's over the fence, perusing the relevant man pages suggests a  
combination of setpgid and tcsetpgrp should get the job done.


But, still: every additional line of code written to implement something is  
an additional line with a potential bug. In a security-sensitive context, it  
won't surprise me if trying to chase the separated server process unicorn  
ends up creating more bugs than a simple suid program ever had in its  
decades' of existence.




pgp4xGszFYaqp.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 on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: conditional require

2022-01-31 Thread Steven A. Falco


On 1/31/22 05:08 PM, Steven A. Falco wrote:

On 1/31/22 04:04 PM, Miro Hrončok wrote:

On 31. 01. 22 21:58, przemek klosowski via devel wrote:

During recent major version update, some files were moved from -doc to , 
and as a result updates of  fail due to a file conflict. Manual update of 
-doc resolves this, of course.

A simple solution would be to declare that 

Required: package-doc >= 6.0.0

but that would force the install of the docs package if it wasn't already there.

Is there a way to declare a dependency only if the other package is 
present/installed? Would

Obsoletes: package-doc < 6.0.0

be the right thing to do?


The right thing to do is:

   Conflicts: package-doc < 6.0.0


Ok, so that doesn't do what I'd like.  I definitely added the conflict property:

# rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 6.0.0

But when I try to upgrade just the kicad package without upgrading the docs 
package, I still get:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm
...
Running transaction test
Error: Transaction test error:
   file /usr/share/doc/kicad/scripts/lib_convert.py from install of 
kicad-1:6.0.1-4.fc35.x86_64 conflicts with file from package 
kicad-doc-1:5.1.12-1.fc35.noarch
   file /usr/share/doc/kicad/scripts/test_kicad_plugin.py from install of 
kicad-1:6.0.1-4.fc35.x86_64 conflicts with file from package 
kicad-doc-1:5.1.12-1.fc35.noarch

So the Conflicts line doesn't actually seem to buy me anything.

I'll try again with the version from Stephen Gallagher (including the epoch) 
and see if that is any better.

The Conflict flag is now set to:

# rpm -q -conflicts kicad-6.0.1-4.fc35.x86_64.rpm
kicad-doc < 1:6.0.1-4.fc35

And the result is:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm
Last metadata expiration check: 0:40:27 ago on Mon 31 Jan 2022 05:06:19 PM EST.
Dependencies resolved.

 Problem: problem with installed package kicad-doc-1:5.1.12-1.fc35.noarch
  - package kicad-1:6.0.1-4.fc35.x86_64 conflicts with kicad-doc < 
1:6.0.1-4.fc35 provided by kicad-doc-1:5.1.12-1.fc35.noarch
  - cannot install the best update candidate for package 
kicad-1:5.1.12-1.fc35.x86_64

 Package  Architecture  Version   Repository
   Size

Skipping packages with conflicts:
(add '--best --allowerasing' to command line to force their upgrade):
 kicadx86_641:6.0.1-4.fc35@commandline  
   90 M

Transaction Summary

Skip  1 Package

When I add the '--best --allowerasing' flags, then I get the desired result:

# dnf update kicad-6.0.1-4.fc35.x86_64.rpm --best --allowerasing
Last metadata expiration check: 0:43:04 ago on Mon 31 Jan 2022 05:06:19 PM EST.
Dependencies resolved.

 PackageArchitectureVersion Repository  
   Size

Upgrading:
 kicad  x86_64  1:6.0.1-4.fc35  @commandline
   90 M
Removing dependent packages:
 kicad-doc  noarch  1:5.1.12-1.fc35 @updates
  111 M

So that looks like the best solution.

Thanks all for the help!

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

Weirdness with clang and stdatomic.h on Rawhide

2022-01-31 Thread Ron Olson

Hey all,

I’m troubleshooting an issue and came up with this sample program: 
https://pastebin.com/g9S8Z64q to demonstrate the problem. Basically, clang 13, 
on Rawhide, won’t compile that program, while on Fedora 35 it does.

The reason why is that on Rawhide, stdatomic.h exists under /usr/include/c++/12 
while it does not exist on 35, so clang uses its built-in stdatomic per 
https://clang.llvm.org/docs/LanguageExtensions.html#c11-atomic-operations. If 
it uses its internal version, the sample program compiles fine.

Looking at stdatomic.h on Rawhide, I see it’s gated by “#if __cplusplus > 
202002L”, so that means C++2b or later, not C++20. This seems to create a 
problem for clang which, since the file is present, wants to use it, but since 
it’s effectively empty due to the #ifdef, compiling of the sample program fails.

Is it possible to disable clang’s use of the header file as a flag? I’ve been 
unable to find anything like that, and obviously renaming the header is out of 
the question.  Also, is it correct to the setting stdatomic.h to only be used 
by c++2b?

Thanks for any info,

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

1 2 >

1 - 100 of 198 matches

Mail list logo