Re: F29 System Wide Change: Strong crypto settings: phase 2

[Paul Wouters]

On Wed, 6 Jun 2018, Nikos Mavrogiannopoulos wrote:


I think the debate here is whether fedora (and in general operating
systems) can afford to be stricter than the browsers. As an OS our
attack surface is much larger than the browser setup, and thus it makes
sense (to me), to be more careful.


Your legacy interaction will also be much larger. Like connecting to
your home wifi router's webgui.


Can we afford to break a significant part of our users? Of course not,
but I think that this change is eventually happening, especially with
TLS1.3 expected to be deployed widely, and it seems to me that we only
wait to see who will do the first step.


I don't think TLS 1.3 will see a wide deployment immediately. Sure, the
famous top websites and top browsers will, but enterprises will not. And
especially those with any kind of loggin/auditing requirements cannot
even allow TLS 1.3 with ephemeral DH on their network.

I would personally first try and disable TLS 1.0 in f29 and see how much
problems that generates. Then in f30 or f31 disable TLS 1.1. But I
suspect fedora itself not to be the problem. The real problems will hit
RHEL/CentOS in the enterprise deployments. So even with a success in
fedora, I would be very careful with drawing any conclusions for
enterprise use.

Paul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HF6BSBVUYOW5SQZPQ6X3JQHEFVA7N7I7/

[Bug 1590341] Upgrade perl-Time-Local to 1.27

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #4 from Fedora Update System  ---
perl-Time-Local-1.270-1.fc28 has been pushed to the Fedora 28 testing
repository. If problems still persist, please make note of it in this bug
report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here:
https://bodhi.fedoraproject.org/updates/FEDORA-2018-e3cabdb631

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/IRTTSFQEJ7UTDKCUP7SIPWYMMCGBKUVN/

Cryptominisat license change

[Jerry James]

I will build cryptominisat 5.6.3 for Rawhide momentarily.  With this
version, the license changes from LGPLv2 to MIT.  This version also carries
an soname bump.  I will rebuild the only dependent package in Fedora,
namely stp.
-- 
Jerry James
http://www.jamezone.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/BQTHFUCTRQCFSZSG5LIXWPYCHCE3UAO6/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Matthew Miller]

On Tue, Jun 12, 2018 at 08:26:52PM +0200, Miro Hrončok wrote:
> On 12.6.2018 20:15, Reindl Harald wrote:
> >>This is more like a security by obscurity approach. This "another layer"
> >>is just one step. It's like putting a duct tape over a keyhole and call
> >>it extra security
> >bullshit
> Thanks for the tone, it is very helpful.

Because of past behavior like this, Harald has been restricted from
posting to this list; he apparently replied and CC'd you on the
message. If you get harassing messages that fit that pattern in the
future, please do not respond but instead report to the Fedora Council.
Thank you.

And Harald: seriously. This is not how we conduct discussion in Fedora.



-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/64A7RPE34TUTHQ7UTAKDZZLK4IJ6CJXH/

Re: Release criteria proposal: installing / removing software

[Matthew Miller]

On Tue, Jun 12, 2018 at 11:35:21AM -0700, Adam Williamson wrote:
> "The installed system must be able to install, remove, and install
> appropriate updates for software with the default console tool for the
> relevant software type (e.g. default console package manager). This
> includes downloading of packages to be installed/updated."

+1 in theory. The wording is a bit awkward, though -- it sounds like
"updates" are things we must be able to install, remove, and install
again. Why not just:

"The installed system must be able to install, remove, and update
software with the default console tool for the relevant software type
(e.g. default console package manager). This includes downloading of
packages to be installed/updated."


-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/F7YKSIWF7537S7RL2AVO5LQ7BLC2CKLA/

[389-devel] 389 DS nightly 2018-06-13 - 61% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/06/13/report-389-ds-base-1.4.0.10-20180612gitf9d19b0.fc28.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/LQPVPEDS5PQ2FDWC5237HBY5PLN4WL7Y/

[Bug 1590581] New: perl-PAR-Packer-1.045 is available

[bugzilla]

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

Bug ID: 1590581
   Summary: perl-PAR-Packer-1.045 is available
   Product: Fedora
   Version: rawhide
 Component: perl-PAR-Packer
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: anon.am...@gmail.com, jples...@redhat.com,
mmasl...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 1.045
Current version/release in rawhide: 1.044-1.fc29
URL: http://search.cpan.org/dist/PAR-Packer/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

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

Based on the information from anitya: 
https://release-monitoring.org/project/3189/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/7UXUFH32IXWCSCBIC2KONBXWTYAKLMWB/

[Bug 1590577] New: perl-Module-Starter-1.74 is available

[bugzilla]

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

Bug ID: 1590577
   Summary: perl-Module-Starter-1.74 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Module-Starter
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 1.74
Current version/release in rawhide: 1.73-2.fc28
URL: http://search.cpan.org/dist/Module-Starter/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

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

Based on the information from anitya: 
https://release-monitoring.org/project/3114/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/GNIC2SQ7KGVDTI7VBKMCGBOTUFEES62H/

Re: Release criteria proposal: installing / removing software

[Adam Williamson]

On Tue, 2018-06-12 at 22:02 +, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jun 12, 2018 at 12:03:51PM -0700, Adam Williamson wrote:
> > On Tue, 2018-06-12 at 20:55 +0200, Miro Hrončok wrote:
> > > On 12.6.2018 20:35, Adam Williamson wrote:
> > > > "The installed system must be able to install, remove, and install
> > > 
> > > Install, remove and update?
> > 
> > That would be simpler but unfortunately loses the "appropriate"
> > wording, which is important. We could make it "appropriately update"
> > but that reads kinda weird to me.
> 
> Miro has a point, this sentence doesn't make sense as is.
> 
> In "The installed system must be able to install, remove, and install
> appropriate updates for software ..." the subject is "updates", so
> both "install" and "remove" apply to it. Another noun must be inserted.

No, it isn't. The sense is:

"The installed system must be able to:

1) install
2) remove
3) install appropriate updates for

software..."

If that isn't sufficiently clear, though, I'll try to reword it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/7R7CFQ7HV6YJTKR3QVD2R72OP4YSNU7E/

Re: Release criteria proposal: installing / removing software

[Zbigniew Jędrzejewski-Szmek]

On Tue, Jun 12, 2018 at 12:03:51PM -0700, Adam Williamson wrote:
> On Tue, 2018-06-12 at 20:55 +0200, Miro Hrončok wrote:
> > On 12.6.2018 20:35, Adam Williamson wrote:
> > > "The installed system must be able to install, remove, and install
> > 
> > Install, remove and update?
> 
> That would be simpler but unfortunately loses the "appropriate"
> wording, which is important. We could make it "appropriately update"
> but that reads kinda weird to me.

Miro has a point, this sentence doesn't make sense as is.

In "The installed system must be able to install, remove, and install
appropriate updates for software ..." the subject is "updates", so
both "install" and "remove" apply to it. Another noun must be inserted.

Something like "The installed system must be able to install and
remove , and install appropriate updates for software ...",
except that  (as you wrote) is not generic enough.

So maybe something like
"The installed system must be able to install, remove, and update the
software with the default console tool for the relevant software type
(e.g. default console package manager). The downloading of any
packages/software must work and the appropriate updates must be used."

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3WHV6LSPJZMPR5KM47RIDXNNQZQGQNNA/

Re: Elections for Council - May 2018 - Result announcement

[Till Maas]

Hi,

On Thu, Jun 07, 2018 at 09:06:34AM -0400, Matthew Miller wrote:
> On Thu, Jun 07, 2018 at 04:34:10AM +0200, Jan Kurik wrote:
> > The elections for Council - May 2018 [1] have concluded, and the
> > results are shown below.
> 
> Welcome, Till! And, thank you Nick for your work on the Council over
> the last year. I really appreciate the perspective and thoughtfulness
> you brought to the role.

Thank you very much Matthew  and thank you Nick for your service! You are
a very engaged contributor and I would have loved to serve the Council
together with you!

Kind regards
Till
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZVPUYCHR5UHZJ2ZKRE3AR4ULYZZHGWWZ/

Re: Release criteria proposal: drop kickstart package criterion

[Adam Williamson]

On Mon, 2018-06-04 at 16:39 -0700, Adam Williamson wrote:
> Hi, folks!
> 
> We currently have a Final release criterion that reads as follows:
> 
> "A spin-kickstarts package which contains the exact kickstart files
> used to build the release must be present in the release repository.
> The included kickstarts must define the correct set of release
> repositories.
> 
> Why?
> 
> This is considered part of Fedora's duty to be 'self-hosting': the
> kickstarts used to produce the release images are a vital piece of
> information required to duplicate that release, so they must be
> preserved along with the release."
> 
> Lately this requirement has been fairly annoying in practice. Updating
> the package prior to release does not appear to be in anyone's regular
> schedule, so invariably what happens is shortly before the release
> deadline I realize we haven't built a 'release' spin-kickstarts package
> and have to file a blocker bug and ping people with the necessary
> permissions (of which there are only a few) to build one in a tearing
> hurry. Then we have to approve the blocker bug and push the updated
> package through the freeze, all wasting time we could be spending on
> more important fixes.
> 
> The benefit here is really fairly tiny, as well. It's arguable whether
> anyone cares particularly whether a Fedora release, as a frozen
> artifact, is 100% internally reproducible (and I'm not sure whether our
> releases actually *are* reproducible in any case, these days, I'm not
> at all sure we ship all the necessary metadata and so on for *every
> single deliverable* within the distribution).
> 
> These days I'd suggest it should be quite acceptable to simply use git
> tags for this purpose. It should be quite easy for rel-eng to adjust
> the release scripts to create a tag in the fedora-kickstarts repo (and
> why not fedora-comps too, while we're at it) for each 'candidate'
> compose, named for the compose ID. That would make it very easy to
> access the correct kickstarts for any Fedora candidate compose just by
> a 'git checkout', with no need for the cumbersome work of getting the
> package into the compose.
> 
> Naturally this would go along with updates to any relevant docs or wiki
> pages, recommending to use the git repository instead of the RPM
> packages, and explaining the tagging scheme. As for the package, we
> could either keep it but not sweat about updating it for each release,
> retire it entirely, or change it to contain only a text file pointing
> to the git repository (or to the doc / wiki page that explains the git
> repo location and tagging strategy).
> 
> Thoughts? Thanks!

So an update on this: as the response has generally been positive I'm
planning to go ahead with it, but I think we should make sure the repo
tagging thing is done *before* we remove the criterion. So I've filed
https://pagure.io/releng/issue/7568 for that. Once that's resolved I'll
go ahead with the criterion removal and docs updates.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/P2VCWJS3NOWTE6W6GQTMM4W3L6USTECG/

Re: CA certificate directory for a VPN client

[Mikhail Zabaluev]

Hi Kai,

2018-06-12 16:55 GMT+03:00 Kai Engert :
>
> If a single CA list for both TLS and VPNs was used, and a user added a
> VPN's private CA to that shared list, it would technically enable the
> VPN operator to issue false certificates, and TLS clients like Firefox
> would then trust such false certificates. This side effect of installing
> a VPN's private CA should be avoided.
>
> Therefore I agree with you, the directory for VPN CAs should be
> configured separately.
>
> Are there any VPNs that use server certificates issued by web CAs? All
> VPNs that I have seen personally used their own CA certificates.

A public VPN service provider might conceivably use a certificate
issued by a well-known public CA to spare the clients the hassle of
installing custom CA certificates.

> > I came up with /etc/pki/vpn, that is not currently populated in
> > Fedora. Would there be a more appropriate choice, governed by PKI
> > policies that I'm not aware of?
>
> If the directory format expected by charon-nm might be different from
> the input expect by other vpn clients, then it might make sense to
> define a directory specifically for charon-nm. If you think it's
> reusable, it might make sense to define the file format expected in that
> directory. For TLS, because different tools require the list of CAs in
> different format, we have chosen the approach that is documented in the
> update-ca-trust(8) manual apge.
>
> Does charon-nm want individual files? Does it expect specific filenames,
> like the hashed filenames that openssl may use? Does it expect files in
> PEM or DER format? Does it support files in which multiple certificates
> are concatenated, or does it accept only one CA per file? These are
> example attributes, that might cause the contents of the directory to
> work only for the charon-nm tool, but not for others.

Accordingly to the documentation and my brief analysis of the code,
charon-nm can load both PEM or DER. It tries to load all files present
in the configured directory as CA certificates, using OpenSSL
functions to parse the formats.
It supports concatenated certificate bundles at least in PEM format; I
verified that it works with the bundle file in
/etc/pki/ca-trust/extracted/openssl. So I think the directory can be
shared between charon-nm and other VPN clients using standard PKI
formats.

Best regards,
  Mikhail
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/RVEHEBDYZBESZM2FAR57L4JIKT5XA2QP/

Re: Release criteria proposal: installing / removing software

[Adam Williamson]

On Tue, 2018-06-12 at 20:55 +0200, Miro Hrončok wrote:
> On 12.6.2018 20:35, Adam Williamson wrote:
> > "The installed system must be able to install, remove, and install
> 
> Install, remove and update?

That would be simpler but unfortunately loses the "appropriate"
wording, which is important. We could make it "appropriately update"
but that reads kinda weird to me.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NH7BL4R73BU3LEMYKROMZKKF4EVXEU3D/

Re: Release criteria proposal: installing / removing software

[Miro Hrončok]

On 12.6.2018 20:35, Adam Williamson wrote:

"The installed system must be able to install, remove, and install


Install, remove and update?

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XIWOHHA4VTNJ5T3KC5YZIGM2NCXAQD5I/

[Bug 1590344] Upgrade perl-Config-Model to 2.124

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-Config-Model-2.124-1.f
   ||c29
 Resolution|--- |RAWHIDE
Last Closed||2018-06-12 14:49:35



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/SWQZM7JDQMQ55BURSJU62JYGWJVOKJOU/

[389-devel] please review: PR 49776 - lib389 CLI tools should return a result code on failures

[Mark Reynolds]

https://pagure.io/389-ds-base/pull-request/49776
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/C7L5RC4IED5K2E7T647HTWNMXZPMV6FK/

Release criteria proposal: installing / removing software

[Adam Williamson]

Hi, folks!

It's been noted a few times before that we have a release criterion
that requires *updating* packages (or, these days, 'software', to cover
things like modules) to work...but we don't have criteria covering
other basic software management tasks, notably installing and removing.
 There is a possible justification for this: so long as update works,
bugs in installation and removal can be fixed with updates. But really,
it seems reasonable to me that we should require basic
installation/removal of packages (and modules, and anything else we may
choose to consider release critical now or in future, e.g. flatpaks,
Shell extensions...) to work on release.

So, I'm proposing we modify the existing Basic and Beta criteria that
cover only updates, to also cover installation and removal. I like this
a bit more than adding separate criteria as the footnotes would be very
similar, and combining allows the footnotes to be shared.

So, the Basic criterion would change from:

"The installed system must be able to download and install appropriate
updates with the default console tool for the relevant update type
(e.g. default console package manager)."

to:

"The installed system must be able to install, remove, and install
appropriate updates for software with the default console tool for the
relevant software type (e.g. default console package manager). This
includes downloading of packages to be installed/updated."

the Beta criterion would similarly change from:

"The installed system must be able to download and install appropriate
updates with the default tool for the relevant update type in all
release-blocking desktops (e.g. default graphical package manager)."

to:

"The installed system must be able to install, remove, and install
appropriate updates for software with the default tool for the relevant
update type in all release-blocking desktops (e.g. default graphical
package manager). This includes downloading of packages to be
installed/updated."

the footnotes would be tweaked to refer more generically to 'software'
and stuff instead of 'updates', just kinda logical changes to reflect
the broadened criterion; I can go into detail on that if anyone wants.

Obviously if the criterion change is agreed upon, we will add test
cases to the test matrices.

Thoughts, comments, suggestions, acks and nacks? Thanks!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/LQIXML42QXJLFJWOYMYXW36QNWFG4FII/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Miro Hrončok]

On 12.6.2018 20:15, Reindl Harald wrote:

This is more like a security by obscurity approach. This "another layer"
is just one step. It's like putting a duct tape over a keyhole and call
it extra security


bullshit


Thanks for the tone, it is very helpful.



when the exploit is naively written it just tries to put a binary in the
directory and on well configured system you don't put ANYTHING in front
of PATH

man chattr

[root@srv-rhsoft:~]$ touch /home/harry/.bashrc
touch: setting times of '/home/harry/.bashrc': Operation not permitted


Excellent. So the file is immutable. Since you were clever enough to 
make it so, you probably care enough to change the line that prepends 
the PATH in there. Or is that too complicated?


We are changing the default and we are saying that it will not lower the 
security. If users want to make steps into increasing security that's 
good. And we are not blocking them by this change.




but luckily Fedora was too long too stupid get rid of /bin and /sbin
after UsrMove so that i don't care about any defaults any longer


Funny how you don't care yet you keep sending the e-mails.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/M32M74CLD6IIHR46XYCDKBJVRSL7GZP6/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Miro Hrončok]

On 12.6.2018 19:57, Reindl Harald wrote:



Am 12.06.2018 um 19:31 schrieb Miro Hrončok:


On 12.6.2018 19:20, Howard Howell wrote:

I haven't followed all of this thread, too self busy.  However there is
a security argument.  If you have a local executable directory, then
the capability for malicious software to attach is wide open for that
user, whatever their privelege level might be.


Executable directory? If you have power over user $HOME, you can change
user's $PATH. I don't know what this have to do with anything being
executable (but maybe I just didn't understand.)


so what - the more you need to change the harder a successful attack
becomes - google for layered security


This is more like a security by obscurity approach. This "another layer" 
is just one step. It's like putting a duct tape over a keyhole and call 
it extra security.


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/M6OIUDG2SKN2Q5IU2TFBHJNNF25JXZJA/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Daniel P . Berrangé]

On Tue, Jun 12, 2018 at 10:20:46AM -0700, Howard Howell wrote:
> I haven't followed all of this thread, too self busy.  However there is
> a security argument.  If you have a local executable directory, then
> the capability for malicious software to attach is wide open for that
> user, whatever their privelege level might be.
> 
> Most businesses that have linux in their suite, won't want a ~/.bin
> anywhere in their organization.

If a malicious attacker have privileges to create/modify $HOME/.bin/foo,
then they will also have privileges to modify $HOME/.bashrc to add any
directory they wish to $PATH. So that security argument doesn't hold water.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B7DIN36VCWSFUBQBU7JXBBWWWUXSDN7X/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Miro Hrončok]

On 12.6.2018 19:20, Howard Howell wrote:

I haven't followed all of this thread, too self busy.  However there is
a security argument.  If you have a local executable directory, then
the capability for malicious software to attach is wide open for that
user, whatever their privelege level might be.


Executable directory? If you have power over user $HOME, you can change 
user's $PATH. I don't know what this have to do with anything being 
executable (but maybe I just didn't understand.)



Most businesses that have linux in their suite, won't want a ~/.bin
anywhere in their organization.


This is already in the PATH for ages.

--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JYUSHTQWFZJLJIEV2XHTLEEQ5F6DKVC7/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Howard Howell]

On Tue, 2018-06-12 at 12:10 +0100, Tomasz Kłoczko wrote:
> On Mon, 11 Jun 2018 at 12:28, Miro Hrončok 
> wrote:
> [..]
> > See the change description.
> 
> OK So here is quoted original email with proposal.
> 
> "I'd like to propose putting the ~/.local/bin in front of the
> /usr/bin on
> the PATH.
> 
> Currently /usr/bin has priority over ~/.local/bin, which causes a
> [bug]
> where the old system-installed executable written in Python (from
> /usr/bin) is launched, but it finds new Python sources (installed
> into
> $HOME) which it doesn't work with and crashes.
> 
> [bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650
> 
> I believe the current configuration breaks the intuitive expectation
> that things installed closer to the user should take priority. That's
> for example how it works with Python.
> Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
> PATH (though Ubuntu has ~/bin) so we can't take guidance there.
> 
> Does anyone see a reason not to prioritize ~/.local/bin over
> /usr/bin?"
> 
> At the end of the proposal is the question about potential reasons
> why
> this change should not be included, and answer on exactly this
> question has been provided in this thread several times in different
> forms and by more than one person.
> 
> Most of us knows that sometimes it is really hard to find answer on
> some question or prove some theories/thesis. Logick gives perfect
> tool
> to open such hard nuts sometimes instantly.
> https://proofwiki.org/wiki/Negation_of_Conditional_implies_Negation_o
> f_Consequent
> So called CPA (Conditional Proof Assumption) says that If it is hard
> to answer on the original question straight just try to negate
> original formula/postulat/question than continue work on negated one.
> I'll add to this thread kind of CPA question:
> 
> What this change fixes, improves or makes possible in context of
> pure/only distribution resources?
> 
> Second part of above question is really crucial. What started
> #1571650
> wend to "proposal" of the change of the distribution resources
> behaviour.
> Was it correct step? What if this ticket would be about "unexpected
> behavior" of the python in case of installing something in /opt? What
> about other prefixes? Does "positive reaction" on such "needs" should
> imply/justify opening discussion on fiddling in distribution OOTB
> $PATH???
> IMO definitely *NO*!!!
> 
> Just FTR: So far I was unable to find in any of the fredesktop.org or
> other specs (https://www.freedesktop.org/wiki/Software/) things like
> requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
> especially on the front of thes env variable). I would be really glad
> to find original reason why paths like /usr/local{bi,sbin} have been
> added to OOTB $PATH and why someone has been thinking that those
> paths
> should be added on the front of the $PATH.
> 
> I can only guess that most of the people reading this thread and
> still
> not able to identify any danger from security angle may be thinking
> that fiddling in the $PATH isn't dangerous or it may be dangerous
> only
> when someone is typing some commands into shell prompt.
> If it is like this this impression is wrong and I'm 100% sure at
> least
> few people (not only me) commenting in this thread could have no any
> difficulty to show that it is really only impression.
> 
> kloczek
> -- 
> Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelin
> es
> List Archives: https://lists.fedoraproject.org/archives/list/devel@li
> sts.fedoraproject.org/message/EI62XGJANQ4ZX3XC3MDQXY5T2UZLQGNY/
I haven't followed all of this thread, too self busy.  However there is
a security argument.  If you have a local executable directory, then
the capability for malicious software to attach is wide open for that
user, whatever their privelege level might be.

Most businesses that have linux in their suite, won't want a ~/.bin
anywhere in their organization.

Les H
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OLCYVX5L74NYFHJJJ76DB5O4MIE2KFPQ/

[Bug 1584611] perl-Net-LibIDN2-1.00-3.fc29 FTBFS: Failed test at t/ 001_basic.t

[bugzilla]

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



--- Comment #8 from Fedora Update System  ---
perl-Net-LibIDN2-1.00-4.fc28 has been pushed to the Fedora 28 stable
repository. If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ISLFPI7IKUCT4OJU47VE7C336776WWBF/

[Bug 1590341] Upgrade perl-Time-Local to 1.27

[bugzilla]

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



--- Comment #2 from Fedora Update System  ---
perl-Time-Local-1.270-1.fc28 has been submitted as an update to Fedora 28.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-e3cabdb631

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/YIUGVSBWKTQZF2Y2Y66T4ZI53KKQYE7O/

[Bug 1590341] Upgrade perl-Time-Local to 1.27

[bugzilla]

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



--- Comment #3 from Fedora Update System  ---
perl-Time-Local-1.270-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2018-2fce33837d

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/73SK6FKYMTTJ6FRXL2KIPGMBIRB2GPBI/

[Bug 1590341] Upgrade perl-Time-Local to 1.27

[bugzilla]

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

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Time-Local-1.270-1.fc2
   ||9



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/NHSLD76Q5NXASUPI2DOTWKJ3HXNARCBQ/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Tomas Mraz]

On Tue, 2018-06-12 at 16:01 +0200, Kai Engert wrote:
> On 06/11/18 15:14, Tomas Mraz wrote:
> > > Okay, so IIUC now, this is an all-or-nothing kind of change.  If
> > > I
> > > elect/need to use LEGACY to administer some old hardware that I
> > > cannot
> > > otherwise connect to using the defaults, then I'm compromising
> > > that
> > > host's security for anything/everything its used for until it's
> > > taken
> > > back off LEGACY and returned to whatever the non-LEGACY is
> > > called. 
> > > Do I
> > > have it right now?
> > 
> > Yes, except one thing. Just by switching to LEGACY it does not mean
> > you're compromising the host's security. The protocol negotiation
> > and
> > ciphersuite ordering still applies and it will use the best
> > available
> > protocol and ciphersuite and not some random insecure protocol
> > version
> > and ciphersuite. The insecure protocols and ciphersuites will be
> > used
> > only in the case the other end does not know anything better.
> 
> Could switching to LEGACY allow some man-in-the-middle downgrade
> attacks, in which an attacker manipulates the initial phases of
> handshakes, and tricks the parties to use a weaker protocol?

No, that would be a bug in the implementation or protocol design. But
there should be no such issue with the current implementations.

-- 
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JOJZOK3N4GL3B6NXIKZKDXJORSHZ7BTZ/

Re: F29 System Wide Change: Strong crypto settings: phase 2

[Kai Engert]

On 06/11/18 15:14, Tomas Mraz wrote:
>> Okay, so IIUC now, this is an all-or-nothing kind of change.  If I
>> elect/need to use LEGACY to administer some old hardware that I
>> cannot
>> otherwise connect to using the defaults, then I'm compromising that
>> host's security for anything/everything its used for until it's taken
>> back off LEGACY and returned to whatever the non-LEGACY is called. 
>> Do I
>> have it right now?
> 
> Yes, except one thing. Just by switching to LEGACY it does not mean
> you're compromising the host's security. The protocol negotiation and
> ciphersuite ordering still applies and it will use the best available
> protocol and ciphersuite and not some random insecure protocol version
> and ciphersuite. The insecure protocols and ciphersuites will be used
> only in the case the other end does not know anything better.

Could switching to LEGACY allow some man-in-the-middle downgrade
attacks, in which an attacker manipulates the initial phases of
handshakes, and tricks the parties to use a weaker protocol?

Kai
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NL36VBZ7FSCXDGABTZXIJHIJEA5FJQB2/

Re: CA certificate directory for a VPN client

[Kai Engert]

On 06/01/18 08:39, Mikhail Zabaluev wrote:
> A question arose about a good choice of the default directory for
> trusted CA certificates over these proposed rpm PRs:
> 
> https://src.fedoraproject.org/rpms/strongswan/pull-request/6
> https://src.fedoraproject.org/rpms/strongswan/pull-request/7
> 
> An IKEv2 client from strongSwan package, charon-nm, needs to be
> configured with a directory name to load trusted X.509 CAs from. The
> CA certificates are used to authenticate VPN servers.
> 
> There are following considerations for the directory choice:
> 
> 1. It should be in /etc so that it can be configured on ostree machines.
> 2. There is a concern with using a subdirectory of
> /etc/pki/ca-trust/extracted : charon-nm has no regard for key usage
> flags, and there are indeed no standardized flags to authorize
> specifically the VPN usage. Trusting by default any CA that is used to
> validate TLS websites may be considered too permissive; small VPN
> operators typically use self-signed or private CA certificates.

If a single CA list for both TLS and VPNs was used, and a user added a
VPN's private CA to that shared list, it would technically enable the
VPN operator to issue false certificates, and TLS clients like Firefox
would then trust such false certificates. This side effect of installing
a VPN's private CA should be avoided.

Therefore I agree with you, the directory for VPN CAs should be
configured separately.

Are there any VPNs that use server certificates issued by web CAs? All
VPNs that I have seen personally used their own CA certificates.


> 3. It would be useful to have a shared CA certificate directory
> configured out of the box for various VPN clients, similarly to how
> /etc/pki/tls/certs can be shared by any applications using TLS.

If a user wants to connect to a specific VPN A, the user might also like
to avoid to connect to a service operated by an attacker that pretends
to be A. If most VPN CAs are private CAs, and haven't been audited in
similar ways as the Mozilla CA Certificate program is doing it, that
might be an argument for shipping an empty directory by default, and
requiring the user to manually install the CA certificate for only the
services they intend to connect to.


> I came up with /etc/pki/vpn, that is not currently populated in
> Fedora. Would there be a more appropriate choice, governed by PKI
> policies that I'm not aware of?

If the directory format expected by charon-nm might be different from
the input expect by other vpn clients, then it might make sense to
define a directory specifically for charon-nm. If you think it's
reusable, it might make sense to define the file format expected in that
directory. For TLS, because different tools require the list of CAs in
different format, we have chosen the approach that is documented in the
update-ca-trust(8) manual apge.

Does charon-nm want individual files? Does it expect specific filenames,
like the hashed filenames that openssl may use? Does it expect files in
PEM or DER format? Does it support files in which multiple certificates
are concatenated, or does it accept only one CA per file? These are
example attributes, that might cause the contents of the directory to
work only for the charon-nm tool, but not for others.

Kai
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/W64BLLOEGMI34AWO6ODUBDDBKEJOXJI5/

Re: Resurrecting python-logilab-common package

[Miro Hrončok]

On 12.6.2018 15:07, Jiri Kucera wrote:

Hello,

I am interested in maintaining python-logilab-common package. It is required by 
python-pylint-common (not yet packaged), which is required by 
python-prospector. I have a plan to add prospector to Fedora. It will be used 
as a csmock plugin if it  catch issues not covered by recent csmock plugins for 
Python.


Feel free to cc me on the package review and I shell take 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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/SWH3A7QO4DANE5UYUOJHII5WLPDBD4T7/

Resurrecting python-logilab-common package

[Jiri Kucera]

Hello,

I am interested in maintaining python-logilab-common package. It is required by 
python-pylint-common (not yet packaged), which is required by 
python-prospector. I have a plan to add prospector to Fedora. It will be used 
as a csmock plugin if it  catch issues not covered by recent csmock plugins for 
Python.

Thanks in advance
Jiri Kucera
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NHUHJBE6YK5RHL4DP33UVAOWK4RX7SBE/

[Bug 1590344] Upgrade perl-Config-Model to 2.124

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|david.hanneq...@gmail.com   |jples...@redhat.com



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/2FVSZ7TCRB7ZCTCGGEXSKFGNOHM5PC7N/

[Bug 1590344] New: Upgrade perl-Config-Model to 2.124

[bugzilla]

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

Bug ID: 1590344
   Summary: Upgrade perl-Config-Model to 2.124
   Product: Fedora
   Version: rawhide
 Component: perl-Config-Model
  Assignee: david.hanneq...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: david.hanneq...@gmail.com,
perl-devel@lists.fedoraproject.org



Latest Fedora delivers 2.123 version. Upstream released 2.124. When you have
free time, please upgrade it

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/ATIEWN2IZA2ZP3FMJ4ZYOBGF7O5AHPES/

[Bug 1590341] New: Upgrade perl-Time-Local to 1.27

[bugzilla]

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

Bug ID: 1590341
   Summary: Upgrade perl-Time-Local to 1.27
   Product: Fedora
   Version: rawhide
 Component: perl-Time-Local
  Assignee: ppi...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest Fedora delivers 1.250 version. Upstream released 1.27. When you have
free time, please upgrade it

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/7NJ2MKD7JCATSKN5RELWIS4JOEUWELCE/

[Bug 1590338] New: Upgrade perl-Net-DNS-SEC to 1.09

[bugzilla]

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

Bug ID: 1590338
   Summary: Upgrade perl-Net-DNS-SEC to 1.09
   Product: Fedora
   Version: rawhide
 Component: perl-Net-DNS-SEC
  Assignee: wjhns...@hardakers.net
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
pwout...@redhat.com, wjhns...@hardakers.net



Latest Fedora delivers 1.08 version. Upstream released 1.09. When you have free
time, please upgrade it

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/VNS3WUYBOUVQWJ5ERFEPBSQPN3UERJ6R/

[Bug 1590333] New: Upgrade perl-Image-ExifTool to 11.01

[bugzilla]

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

Bug ID: 1590333
   Summary: Upgrade perl-Image-ExifTool to 11.01
   Product: Fedora
   Version: rawhide
 Component: perl-Image-ExifTool
  Assignee: tcall...@redhat.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org,
tcall...@redhat.com



Latest Fedora delivers 11.00 version. Upstream released 11.01. When you have
free time, please upgrade it

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/75LTKMPJEUX7ZG6N7K4BGXTS765RLR4A/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Matthew Miller]

On Tue, Jun 12, 2018 at 07:50:29AM -0400, Nico Kadel-Garcia wrote:
> The simple fact is that "sudo" inherits $HOME and $PATH by default.

Not in Fedora's default configuration. And, this proposal increases my
support for keeping that as it is (with secure_path set).

-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/3PTRM34L2DP7IT564I2FHMYVJGSFPSCC/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Kyle Marek]

On 06/12/2018 07:50 AM, Nico Kadel-Garcia wrote:
> On Tue, Jun 12, 2018 at 7:10 AM, Tomasz Kłoczko
>  wrote:
>
>> Just FTR: So far I was unable to find in any of the fredesktop.org or
>> other specs (https://www.freedesktop.org/wiki/Software/) things like
>> requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
>> especially on the front of thes env variable). I would be really glad
>> to find original reason why paths like /usr/local{bi,sbin} have been
>> added to OOTB $PATH and why someone has been thinking that those paths
>> should be added on the front of the $PATH.
> Most of them aren't worried enough about it, or don't have enough
> history to see underlying problems. Most think, and I'm pretty sure of
> this, that you've gotten the security explanations done repeatedly and
> seem to have ignored them. They're certainly not actually spelled out
> in your analysis.
>
> The simple fact is that "sudo" inherits $HOME and $PATH by default.
> Your proposed change would make privilege escalation attacks against
> sudo users much more trivial by opening up the attack surface for
> every binary in /bin or /usr/bin to be replaced by a local binary in
> ~/.local/bin/. The situation you're trying to resolve, where a
> powerful binary has intermingled components that may or not be matched
> by system components, has been resolved repeatedly by tools like rvm
> and pyvenv, by setting up a specific directory *not* enabled by
> default, but making setup for that less default enabled tool easy for
> the user to enable on a case by case basis.
>
> So, the risk of your change is high for others, the consequences are
> potentially *disastrous*,  and you've already got workarounds for your
> particular needs *without* touching other system behavior  If you
> really want it for youself as a user, which I do not recommend for
> such a tool, well, you can insist on doing it for your own individual
> needs on a case by case basis.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QHIKORMDVMA4JNRKYLO2M7LLLAY25R3U/

`sudo` inheriting the user's path is a security issue, in itself.

Also note that Fedora's default sudo config does not allow $PATH
inheritance, anyway.

See sudo(8), section "ENVIRONMENT": PATH    May be overridden by the
security policy.

kmarek@localhost.localdomain ~
$ sh -c 'echo $PATH'
/usr/libexec/python3-sphinx:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/home/kmarek/.local/bin:/home/kmarek/bin

kmarek@localhost.localdomain ~
$ sudo sh -c 'echo $PATH'
/sbin:/bin:/usr/sbin:/usr/bin

kmarek@localhost.localdomain ~
$ env PATH=/nonexistent /usr/bin/sudo env | grep ^PATH=
PATH=/sbin:/bin:/usr/sbin:/usr/bin

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/NYKLV7AGO5OXLAWUSLYMNADJN5FITQM6/

[Bug 1590332] New: Upgrade perl-Devel-CheckLib to 1.13

[bugzilla]

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

Bug ID: 1590332
   Summary: Upgrade perl-Devel-CheckLib to 1.13
   Product: Fedora
   Version: rawhide
 Component: perl-Devel-CheckLib
  Assignee: de...@fateyev.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: de...@fateyev.com, jose.p.oliveira@gmail.com,
perl-devel@lists.fedoraproject.org



Latest Fedora delivers 1.11 version. Upstream released 1.13. When you have free
time, please upgrade it

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/CKAO4JBTBQBQ65VPAFFADWEWD4AYWPC3/

[Bug 1590331] New: Upgrade perl-Class-Date to 1.1.17

[bugzilla]

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

Bug ID: 1590331
   Summary: Upgrade perl-Class-Date to 1.1.17
   Product: Fedora
   Version: rawhide
 Component: perl-Class-Date
  Assignee: oss...@gmail.com
  Reporter: jples...@redhat.com
QA Contact: extras...@fedoraproject.org
CC: oss...@gmail.com, perl-devel@lists.fedoraproject.org



Latest Fedora delivers 1.1.16 version. Upstream released 1.1.17. When you have
free time, please upgrade it

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/YQ3GEGK26OL6CXM7ICKLRXFEWFWU7DKH/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Daniel P . Berrangé]

On Tue, Jun 12, 2018 at 07:50:29AM -0400, Nico Kadel-Garcia wrote:
> On Tue, Jun 12, 2018 at 7:10 AM, Tomasz Kłoczko
>  wrote:
> 
> > Just FTR: So far I was unable to find in any of the fredesktop.org or
> > other specs (https://www.freedesktop.org/wiki/Software/) things like
> > requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
> > especially on the front of thes env variable). I would be really glad
> > to find original reason why paths like /usr/local{bi,sbin} have been
> > added to OOTB $PATH and why someone has been thinking that those paths
> > should be added on the front of the $PATH.
> 
> Most of them aren't worried enough about it, or don't have enough
> history to see underlying problems. Most think, and I'm pretty sure of
> this, that you've gotten the security explanations done repeatedly and
> seem to have ignored them. They're certainly not actually spelled out
> in your analysis.
> 
> The simple fact is that "sudo" inherits $HOME and $PATH by default.
> Your proposed change would make privilege escalation attacks against
> sudo users much more trivial by opening up the attack surface for
> every binary in /bin or /usr/bin to be replaced by a local binary in
> ~/.local/bin/.

No, it doesn't increase the risk. If someone has privs to create
binaries in $HOME/.local/bin, then they can already change $HOME
and $PATH env vars. If this attack scenario is a concern, then
change sudo to not honour env variables like $HOME/$PATH at all.

Regards,
Daniel
-- 
|: https://berrange.com  -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-photo.org-o-https://www.instagram.com/dberrange :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QHL7XRN77UYAXOY5DT4SZ4T7YXT6EDPE/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Miro Hrončok]

On 12.6.2018 13:50, Nico Kadel-Garcia wrote:

On Tue, Jun 12, 2018 at 7:10 AM, Tomasz Kłoczko
 wrote:


Just FTR: So far I was unable to find in any of the fredesktop.org or
other specs (https://www.freedesktop.org/wiki/Software/) things like
requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
especially on the front of thes env variable). I would be really glad
to find original reason why paths like /usr/local{bi,sbin} have been
added to OOTB $PATH and why someone has been thinking that those paths
should be added on the front of the $PATH.


Most of them aren't worried enough about it, or don't have enough
history to see underlying problems. Most think, and I'm pretty sure of
this, that you've gotten the security explanations done repeatedly and
seem to have ignored them. They're certainly not actually spelled out
in your analysis.

The simple fact is that "sudo" inherits $HOME and $PATH by default.
Your proposed change would make privilege escalation attacks against
sudo users much more trivial by opening up the attack surface for
every binary in /bin or /usr/bin to be replaced by a local binary in
~/.local/bin/. The situation you're trying to resolve, where a
powerful binary has intermingled components that may or not be matched
by system components, has been resolved repeatedly by tools like rvm
and pyvenv, by setting up a specific directory *not* enabled by
default, but making setup for that less default enabled tool easy for
the user to enable on a case by case basis.

So, the risk of your change is high for others, the consequences are
potentially *disastrous*,  and you've already got workarounds for your
particular needs *without* touching other system behavior  If you
really want it for youself as a user, which I do not recommend for
such a tool, well, you can insist on doing it for your own individual
needs on a case by case basis.


If somebody can write to your $HOME, they can change your $PATH. Hence 
the disaster is already happening and this change doesn't make it any 
more insecure than it already is.


Please read 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/OXXC5NOZP37W2F6GHV6P5E6K22QHOBNJ/ 
- this has already been discussed there.


--
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4FQJUIWIGHQJM5VFZO2E6IPFI45R2Z4U/

Re: ga (global arrays) package maintainer needed

[Robert-André Mauchin]

On mardi 12 juin 2018 10:57:34 CEST abdul@wipro.com wrote:
> Hello Team,
> 
> Can you please remove my Email from the Distribution list ?
> I've been requesting the same from long time and no action has been taken.
> 

To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/E3F6QWN6EAZBJ7QQOBPANL7BESS7YC6H/

[Bug 1589598] perl-File-ShareDir-1.106 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|ASSIGNED|CLOSED
   Fixed In Version||perl-File-ShareDir-1.106-1.
   ||fc29
 Resolution|--- |RAWHIDE
Last Closed||2018-06-12 07:53:56



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/YPK3ZRJ2G73TJ5XAOHJEBCURBYAH3TYO/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Nico Kadel-Garcia]

On Tue, Jun 12, 2018 at 7:10 AM, Tomasz Kłoczko
 wrote:

> Just FTR: So far I was unable to find in any of the fredesktop.org or
> other specs (https://www.freedesktop.org/wiki/Software/) things like
> requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
> especially on the front of thes env variable). I would be really glad
> to find original reason why paths like /usr/local{bi,sbin} have been
> added to OOTB $PATH and why someone has been thinking that those paths
> should be added on the front of the $PATH.

Most of them aren't worried enough about it, or don't have enough
history to see underlying problems. Most think, and I'm pretty sure of
this, that you've gotten the security explanations done repeatedly and
seem to have ignored them. They're certainly not actually spelled out
in your analysis.

The simple fact is that "sudo" inherits $HOME and $PATH by default.
Your proposed change would make privilege escalation attacks against
sudo users much more trivial by opening up the attack surface for
every binary in /bin or /usr/bin to be replaced by a local binary in
~/.local/bin/. The situation you're trying to resolve, where a
powerful binary has intermingled components that may or not be matched
by system components, has been resolved repeatedly by tools like rvm
and pyvenv, by setting up a specific directory *not* enabled by
default, but making setup for that less default enabled tool easy for
the user to enable on a case by case basis.

So, the risk of your change is high for others, the consequences are
potentially *disastrous*,  and you've already got workarounds for your
particular needs *without* touching other system behavior  If you
really want it for youself as a user, which I do not recommend for
such a tool, well, you can insist on doing it for your own individual
needs on a case by case basis.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QHIKORMDVMA4JNRKYLO2M7LLLAY25R3U/

Re: REMINDER: Submission deadline for Changes of Fedora 29 requiring mass rebuild takes effect in one week

[Alain Vigne]

Thanks...
I was wondering how introduction of a new package enters such schedule [1] ?
More specifically, when is the deadline for a new package to enter Fedora
29 ?

I recall my introduction from 5 days ago, stating I volunteer to maintain a
new EDA package (and co-maintain others ?) :
"
Hi,
I am Alain, a French EE engineer using Fedora 28 and EDA open source tools,
as an hobby.

I am part of the pcb-rnd developer upstream
http://repo.hu/projects/pcb-rnd/
and was able to produce a .spec file + SRPM rpm file, and COPR successful
build:
https://copr.fedorainfracloud.org/coprs/avigne/pcb-rnd/

Now, I am looking for a sponsor to get this package into Fedora. I filled
this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1581240

I volunteer to be the package maintainer, have read the guidelines and
acknowledge responsibilities requested for such a task.
My FAS username is: avigne

This package could also be part of FEL (Fedora Electronic Lab) spin, to be
revived ?

Hoping for some positive feed-back...
Best regards
"


On Tue, Jun 12, 2018 at 9:27 AM, Jan Kurik  wrote:

> Hi everyone!
>
> The submission deadline for Changes of Fedora 29 [1], requiring mass
> rebuild, takes effect in one week on June 19th. All the Changes
> requiring mass rebuild sent for review after this deadline are going
> to be moved to Fedora 30 release.
> The mass rebuild it self is planned on July 11th.
>
> The deadline for System Wide Changes which do not need the mass
> rebuild is planned on July 3rd.
>
> If your Change proposal needs mass rebuild, please submit it by the
> deadline, earlier better. In case you'll need any help with your
> Change proposals, feel free to contact me.
>
> [1] https://fedoraproject.org/wiki/Releases/29/Schedule
>
> Best Regards,
> Jan
> --
> Jan Kuřík
> JBoss EAP Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.
> fedoraproject.org/message/B25U3IVRNCXUTPLGPZCJQJ2MKXRDOF42/
>



-- 
Alain V.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J2AOLQ66XOTPXJYCKGQSWWAK7D3P3FZ4/

Re: Prioritizing ~/.local/bin over /usr/bin on the PATH

[Tomasz Kłoczko]

On Mon, 11 Jun 2018 at 12:28, Miro Hrončok  wrote:
[..]
> See the change description.

OK So here is quoted original email with proposal.

"I'd like to propose putting the ~/.local/bin in front of the /usr/bin on
the PATH.

Currently /usr/bin has priority over ~/.local/bin, which causes a [bug]
where the old system-installed executable written in Python (from
/usr/bin) is launched, but it finds new Python sources (installed into
$HOME) which it doesn't work with and crashes.

[bug] https://bugzilla.redhat.com/show_bug.cgi?id=1571650

I believe the current configuration breaks the intuitive expectation
that things installed closer to the user should take priority. That's
for example how it works with Python.
Interestingly, ubuntu and opensuse do not have ~/.local/bin on their
PATH (though Ubuntu has ~/bin) so we can't take guidance there.

Does anyone see a reason not to prioritize ~/.local/bin over /usr/bin?"

At the end of the proposal is the question about potential reasons why
this change should not be included, and answer on exactly this
question has been provided in this thread several times in different
forms and by more than one person.

Most of us knows that sometimes it is really hard to find answer on
some question or prove some theories/thesis. Logick gives perfect tool
to open such hard nuts sometimes instantly.
https://proofwiki.org/wiki/Negation_of_Conditional_implies_Negation_of_Consequent
So called CPA (Conditional Proof Assumption) says that If it is hard
to answer on the original question straight just try to negate
original formula/postulat/question than continue work on negated one.
I'll add to this thread kind of CPA question:

What this change fixes, improves or makes possible in context of
pure/only distribution resources?

Second part of above question is really crucial. What started #1571650
wend to "proposal" of the change of the distribution resources
behaviour.
Was it correct step? What if this ticket would be about "unexpected
behavior" of the python in case of installing something in /opt? What
about other prefixes? Does "positive reaction" on such "needs" should
imply/justify opening discussion on fiddling in distribution OOTB
$PATH???
IMO definitely *NO*!!!

Just FTR: So far I was unable to find in any of the fredesktop.org or
other specs (https://www.freedesktop.org/wiki/Software/) things like
requirement use /usr/local{bi,sbin} or ~.local/bin in $PATH (and
especially on the front of thes env variable). I would be really glad
to find original reason why paths like /usr/local{bi,sbin} have been
added to OOTB $PATH and why someone has been thinking that those paths
should be added on the front of the $PATH.

I can only guess that most of the people reading this thread and still
not able to identify any danger from security angle may be thinking
that fiddling in the $PATH isn't dangerous or it may be dangerous only
when someone is typing some commands into shell prompt.
If it is like this this impression is wrong and I'm 100% sure at least
few people (not only me) commenting in this thread could have no any
difficulty to show that it is really only impression.

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EI62XGJANQ4ZX3XC3MDQXY5T2UZLQGNY/

RE: ga (global arrays) package maintainer needed

[abdul....@wipro.com]

Hello Team,

Can you please remove my Email from the Distribution list ?
I've been requesting the same from long time and no action has been taken.

-Original Message-
From: Petr Pisar [mailto:ppi...@redhat.com]
Sent: 12 June 2018 13:58
To: devel@lists.fedoraproject.org
Subject: Re: ga (global arrays) package maintainer needed

** This mail has been sent from an external source **

On 2018-06-12, Marcin Dulak  wrote:
> What is the current policy about bundling in Fedora?
>
.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an 
email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://clicktime.symantec.com/a/1/EqN76q5c50Sx-4QTGgoTYjkENblcJ-HLsYsBLRNOOY4=?d=Vz0KNPVaf5ukle5EwPgk8x9P99eSdAE49dzwRCkIf80vtuSh9U4QuK7b_k7mmocYI9wLtmwp5D5DSW32qAf_JviCZF-BMrCUhk2LLYBtjn91x8smdyvuYF8MgsNPzOHEMyC7OafLGkMK9FUQIylUvkwa3N9ySR4eAf7iHKmygi4xe1IvZ3n4zxNmwA3aAIyuX3XABgIs6aTQG_g53ecmpr7FhTdO1nSsn1eIIdcZ1og7X9iDKKL1I8iGJ8J8kp7d_dJUy5cXFB_HzHYLFFm5DVtBe1lJqzHCHg5ClIAqYZSBOJlN523b4ObSP7Q91AWhcYztgzNbxecsuukpMB36Sk6ttcr48EKlb4ouJCxi7Igj_JUuOzLR_45Yd-1g9__vi1Ia6JJC1HK-hn0Gni5CKrLmkP8pLIapr5wE=https%3A%2F%2Fgetfedora.org%2Fcode-of-conduct.html
List Guidelines: 
https://clicktime.symantec.com/a/1/5O8pC04v2dgfpOQiHYvGnGIoIEDGb2UUD5HuZYVgmL0=?d=Vz0KNPVaf5ukle5EwPgk8x9P99eSdAE49dzwRCkIf80vtuSh9U4QuK7b_k7mmocYI9wLtmwp5D5DSW32qAf_JviCZF-BMrCUhk2LLYBtjn91x8smdyvuYF8MgsNPzOHEMyC7OafLGkMK9FUQIylUvkwa3N9ySR4eAf7iHKmygi4xe1IvZ3n4zxNmwA3aAIyuX3XABgIs6aTQG_g53ecmpr7FhTdO1nSsn1eIIdcZ1og7X9iDKKL1I8iGJ8J8kp7d_dJUy5cXFB_HzHYLFFm5DVtBe1lJqzHCHg5ClIAqYZSBOJlN523b4ObSP7Q91AWhcYztgzNbxecsuukpMB36Sk6ttcr48EKlb4ouJCxi7Igj_JUuOzLR_45Yd-1g9__vi1Ia6JJC1HK-hn0Gni5CKrLmkP8pLIapr5wE=https%3A%2F%2Ffedoraproject.org%2Fwiki%2FMailing_list_guidelines
List Archives: 
https://clicktime.symantec.com/a/1/GGlJRZi2aOtpdCnu42ij8Nr1U_fQ3oK6N_No5-vExKc=?d=Vz0KNPVaf5ukle5EwPgk8x9P99eSdAE49dzwRCkIf80vtuSh9U4QuK7b_k7mmocYI9wLtmwp5D5DSW32qAf_JviCZF-BMrCUhk2LLYBtjn91x8smdyvuYF8MgsNPzOHEMyC7OafLGkMK9FUQIylUvkwa3N9ySR4eAf7iHKmygi4xe1IvZ3n4zxNmwA3aAIyuX3XABgIs6aTQG_g53ecmpr7FhTdO1nSsn1eIIdcZ1og7X9iDKKL1I8iGJ8J8kp7d_dJUy5cXFB_HzHYLFFm5DVtBe1lJqzHCHg5ClIAqYZSBOJlN523b4ObSP7Q91AWhcYztgzNbxecsuukpMB36Sk6ttcr48EKlb4ouJCxi7Igj_JUuOzLR_45Yd-1g9__vi1Ia6JJC1HK-hn0Gni5CKrLmkP8pLIapr5wE=https%3A%2F%2Flists.fedoraproject.org%2Farchives%2Flist%2Fdevel%40lists.fedoraproject.org%2Fmessage%2FOS5U75NCZUYP6YMANH7O7XIBSZOCEE37%2F
The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments. WARNING: Computer viruses can be transmitted via email. The 
recipient should check this email and any attachments for the presence of 
viruses. The company accepts no liability for any damage caused by any virus 
transmitted by this email. www.wipro.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/HQYQDKDVPWU2RVYBRP4E5TKFTMT3MKQS/

Re: ga (global arrays) package maintainer needed

[Petr Pisar]

On 2018-06-12, Marcin Dulak  wrote:
> What is the current policy about bundling in Fedora?
>
.

-- Petr
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/OS5U75NCZUYP6YMANH7O7XIBSZOCEE37/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

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



--- Comment #2 from Petr Pisar  ---
Please note that all Fedoras, RHSCLs and RHEL ≥ 7 do not provide Archive::Tar
module by perl source package, but by perl-Archive-Tar source package.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/5EX52U6KVHKTYMDENA2QXUFJBDDH6VUW/

[Bug 1588760] CVE-2018-12015 perl: Directory traversal in Archive::Tar

[bugzilla]

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

Cedric Buissart  changed:

   What|Removed |Added

 Whiteboard|impact=low,public=20180607, |impact=low,public=20180607,
   |reported=20180607,source=cv |reported=20180607,source=cv
   |e,cvss3=3.3/CVSS:3.0/AV:L/A |e,cvss3=3.3/CVSS:3.0/AV:L/A
   |C:L/PR:N/UI:R/S:U/C:N/I:L/A |C:L/PR:N/UI:R/S:U/C:N/I:L/A
   |:N,cwe=CWE-22,fedora-all/pe |:N,cwe=CWE-22,fedora-all/pe
   |rl=affected,rhel-5/perl=new |rl=affected,rhel-5/perl=new
   |,rhel-6/perl=new,rhel-7/per |,rhel-6/perl=new,rhel-7/per
   |l=new,rhel-8/perl=new,rhscl |l=affected,rhel-8/perl=new,
   |-3/rh-perl526-perl=new,rhsc |rhscl-3/rh-perl526-perl=new
   |l-3/rh-perl524-perl=new,rhs |,rhscl-3/rh-perl524-perl=ne
   |cl-3/rh-perl520-perl=new|w,rhscl-3/rh-perl520-perl=n
   ||ew



-- 
You are receiving this mail because:
You are on the CC list for the bug.
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org/message/C4ZMKNM7GR6DIHOWEG53FCWNKB7FNUSM/

Re: ga (global arrays) package maintainer needed

[Marcin Dulak]

What is the current policy about bundling in Fedora?

It turns out that the global arrays package, apart from being outdated, and no 
response from the maintainer has been compiled with incompatible options
to the ones required by nwchem: 
https://bugzilla.redhat.com/show_bug.cgi?id=1514542

If I don't receive any response I'll start bundling ga (in the sense of using 
the required ga version during the nwchem build).

Marcin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/GV6AAI4DZOYFLBAZSE5YPVBZERKBJGKW/

REMINDER: Submission deadline for Changes of Fedora 29 requiring mass rebuild takes effect in one week

[Jan Kurik]

Hi everyone!

The submission deadline for Changes of Fedora 29 [1], requiring mass
rebuild, takes effect in one week on June 19th. All the Changes
requiring mass rebuild sent for review after this deadline are going
to be moved to Fedora 30 release.
The mass rebuild it self is planned on July 11th.

The deadline for System Wide Changes which do not need the mass
rebuild is planned on July 3rd.

If your Change proposal needs mass rebuild, please submit it by the
deadline, earlier better. In case you'll need any help with your
Change proposals, feel free to contact me.

[1] https://fedoraproject.org/wiki/Releases/29/Schedule

Best Regards,
Jan
-- 
Jan Kuřík
JBoss EAP Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/B25U3IVRNCXUTPLGPZCJQJ2MKXRDOF42/

[389-devel] 389 DS nightly 2018-06-12 - 62% PASS

[vashirov]

https://fedorapeople.org/groups/389ds/ci/nightly/2018/06/12/report-389-ds-base-1.4.0.10-20180612gitf9d19b0.fc28.x86_64.html
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org/message/QP5GXXJNSI5SL2TAXAQDEENSJG3AV5QF/