Re: Packagers - Flag day 2016 Important changes

[Petr Spacek]

On 13.12.2016 22:57, Tom Hughes wrote:
> On 13/12/16 21:32, Simo Sorce wrote:
>> On Tue, 2016-12-13 at 18:52 +, Tom Hughes wrote:
>>
>>> The main goal of long random passwords after all is about a combination
>>> of making them hard to brute force and ensuring that every service has a
>>> unique password to guard against credential reuse attacks when one of
>>> the many services everybody has logins for experiences the inevitable
>>> loss of their poorly secured database.
>>>
>>> I always find it somewhat depressing that the more sophisticated a login
>>> system becomes the worse my security on it seems to get because I wind
>>> up having to use weaker passwords. Banks are the classic example because
>>> they rarely have a straightforward password even as one part of their
>>> authentication but anything that means I have to remember a password
>>> hits the same problem.
>>
>> Don't remember it if it bothers you, why do you use a double standard if
>> the password is not sent via browser but through a CLI ?
> 
> It's an interesting question, and the first thing I'd say is that there are
> actually very few passwords that I enter at a CLI at all. Once I've unlocked
> gnome keyring by logging into my laptop or desktop it's mostly only when I
> want to sudo as other things tend to be by ssh public key auth from my 
> keyring.
> 
> I think the threat model is very different as well, at least for me, as the
> environments where I am entering a password for sudo for example are all ones
> which I control and where I know how the password database is stored while for
> web based logins I operate on the basis that I have no idea whether any given
> site has the sense to hash it's passwords or to adequately protect it's user
> database.
> 
> Obviously I'm sure the FAS database is properly protected but the ways of
> working I have developed are based around not assuming that for web logins
> hence why I switched to random passwords and a password manager many years 
> ago.
> 
> Anyway, it looks like like GOA with the realmd fix likely does what I want,
> which is good news.

Theoretically, if you really really want random password and never type it,
you can retrieve keytab for your account. The keytab file can contain e.g.
random 256 bit AES key so you will as safe as you can, assuming no attacker
can gain access to that file (which you assume already).

In Kerberized world this is usually done for machine/service accounts but
technically nothing prevents you from using the same method for your own 
account.

See man page for command ipa-getkeytab from package freeipa-client (or use
command kpasswd).

-- 
Petr Spacek  @  Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1397731] CVE-2015-8978 perl-SOAP-Lite: XML exponential entity expansion denial-of-service

[bugzilla]

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

Doran Moppert  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 Resolution|--- |WONTFIX
Last Closed||2016-12-14 02:15:19



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

[Bug 1397731] CVE-2015-8978 perl-SOAP-Lite: XML exponential entity expansion denial-of-service

[bugzilla]

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

Doran Moppert  changed:

   What|Removed |Added

 Whiteboard|impact=moderate,public=2015 |impact=moderate,public=2015
   |0721,reported=20161122,sour |0721,reported=20161122,sour
   |ce=cve,cvss2=4.3/AV:N/AC:M/ |ce=cve,cvss2=4.3/AV:N/AC:M/
   |Au:N/C:N/I:N/A:P,cvss3=3.3/ |Au:N/C:N/I:N/A:P,cvss3=3.3/
   |CVSS:3.0/AV:L/AC:L/PR:N/UI: |CVSS:3.0/AV:L/AC:L/PR:N/UI:
   |R/S:U/C:N/I:N/A:L,cwe=CWE-4 |R/S:U/C:N/I:N/A:L,cwe=CWE-4
   |00,fedora-all/perl-SOAP-Lit |00,fedora-all/perl-SOAP-Lit
   |e=notaffected,epel-all/perl |e=notaffected,epel-all/perl
   |-SOAP-Lite=affected,rhel-6/ |-SOAP-Lite=affected,rhel-6/
   |perl-SOAP-Lite=wontfix,rhn_ |perl-SOAP-Lite=wontfix,rhn_
   |proxy_5.6/perl-SOAP-Lite=af |proxy_5.6/perl-SOAP-Lite=wo
   |fected,rhn_satellite_5/perl |ntfix,rhn_satellite_5/perl-
   |-SOAP-Lite=affected |SOAP-Lite=wontfix



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

[Bug 1397731] CVE-2015-8978 perl-SOAP-Lite: XML exponential entity expansion denial-of-service

[bugzilla]

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



--- Comment #3 from Doran Moppert  ---
Statement:

Red Hat Product Security has rated this issue as having Moderate security
impact. This issue is not currently planned to be addressed in future
updates. For additional information, refer to the Issue Severity
Classification: https://access.redhat.com/security/updates/classification/.

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

[Bug 1397731] CVE-2015-8978 perl-SOAP-Lite: XML exponential entity expansion denial-of-service

[bugzilla]

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

Doran Moppert  changed:

   What|Removed |Added

 Whiteboard|impact=moderate,public=2015 |impact=moderate,public=2015
   |0721,reported=20161122,sour |0721,reported=20161122,sour
   |ce=cve,cvss2=4.3/AV:N/AC:M/ |ce=cve,cvss2=4.3/AV:N/AC:M/
   |Au:N/C:N/I:N/A:P,cvss3=3.3/ |Au:N/C:N/I:N/A:P,cvss3=3.3/
   |CVSS:3.0/AV:L/AC:L/PR:N/UI: |CVSS:3.0/AV:L/AC:L/PR:N/UI:
   |R/S:U/C:N/I:N/A:L,cwe=CWE-4 |R/S:U/C:N/I:N/A:L,cwe=CWE-4
   |00,fedora-all/perl-SOAP-Lit |00,fedora-all/perl-SOAP-Lit
   |e=notaffected,epel-all/perl |e=notaffected,epel-all/perl
   |-SOAP-Lite=affected,rhel-6/ |-SOAP-Lite=affected,rhel-6/
   |perl-SOAP-Lite=new,rhn_prox |perl-SOAP-Lite=wontfix,rhn_
   |y_5.6/perl-SOAP-Lite=new,rh |proxy_5.6/perl-SOAP-Lite=af
   |n_satellite_5/perl-SOAP-Lit |fected,rhn_satellite_5/perl
   |e=new   |-SOAP-Lite=affected



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

Re: CVE-2016-8655, systemd, and Fedora

[Scott Schmit]

On Tue, Dec 13, 2016 at 05:54:54PM +0100, Florian Weimer wrote:
> On 12/13/2016 12:17 PM, Lennart Poettering wrote:
> > On Mon, 12.12.16 21:22, Paul Wouters (p...@nohats.ca) wrote:
> > > For us (libreswan) it probably makes less sense to restrict address
> > > family in the daemon. Our daemon just listens to UDP 500/4500, so it
> > > would never be affected by any other kind of address families.
> > 
> > Well, if it creates that UDP socket itself then it needs access to
> > AF_INET, and AF_INET6 at least. And things like syslog() usually imply
> > AF_UNIX, hence it would probably be a good idea to add
> > "RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX" if your service
> > really needs nothing else. That way the service will lose access to
> > AF_PACKET, AF_NETLINK, AF_BLUETOOTH, … and everything else.
> 
> Proper IPv6 support requires AF_NETLINK, too.

IPsec requires AF_NETLINK (NETLINK_XFRM) to manage the security
associations & security policies.  libreswan probably also needs to be
able to manage the routing for IPsec tunnels (NETLINK_ROUTE[6]).

The original RFCs for IPv6 mandated support for IPsec, but that's no
longer required as of RFC 6434.  Nothing else popped out at me as
necessary for IPv6, but it's probably a moot point given XFRM.

So "RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK" is
probably enough? :)


smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Golang 1.8

[jfilak]

I agree with Zbyzsek on this.




What about to carry a tiny down-stream patch until this issue is fixed:

https://github.com/golang/go/issues/18304
(https://github.com/golang/go/issues/18304)








Jakub






-- Původní zpráva --
Od: Zbigniew Jędrzejewski-Szmek 
Komu: Development discussions related to Fedora 
Datum: 13. 12. 2016 19:35:01
Předmět: Re: F26 System Wide Change: Golang 1.8

"On Tue, Dec 13, 2016 at 01:06:29PM -0500, Jakub Cajka wrote:
> > can we enable coredumping for Go programs by default - i.e. set 
GOTRACEBACK=
> > crash?
> > 
> > Currently, Go terminate  a process that panic and prints out an error
> > message on stderr.
> > 
> > This approach does not provide much room for automatic Go panic 
detection.
> 
> It should be possible without any significant side effects apart from 
generating cores and traces. But to enable this, I believe, it would need 
alteration to the default system env. 

Would it be possible? What is the package providing the default env vars?

systemd has DefaultEnvironment= in /etc/systemd/system.conf, but it is
supposed to be used to create local overrides, and doesn't work well
for this case (it's %config(noreplace) among other problems). In general
setting global env vars does not work.

Instead, it would be nicer to modify the go runtime to default to a coredump
if GOTRACEBACK= is not set. This would cover more cases and would not 
pollute
the environment for users who are not using go.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
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

Re: Packagers - Flag day 2016 Important changes

[Ralf Corsepius]

On 12/13/2016 07:19 PM, Simo Sorce wrote:

On Tue, 2016-12-13 at 14:36 +, Dave Love wrote:

Simo Sorce  writes:


If you really need to automate it because typing a password is too hard:
cat ~/.mykrbpassword | kinit myusername


It needs to be automated principally because the password is not
memorable.  I assume infrastructure people would rather we don't use the
least secure credentials we can.


It is the same password you had to use every day to access services like
bodhi, pkgdb, fas, etc...


Not quite.

I did not have to access it when working on packages in a git clone on 
with koji/git/fedpkg - Now I have to.


Ralf


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

Re: F26 System Wide Change: Golang 1.8

[jfilak]

Oh drat, I was hoping for a build time configuration option:

https://github.com/golang/go/issues/18304





Anyway, the env variable could be exported in the /etc/profile file which is
owned by the setup package. However, I don't think it is a good idea to 
place it there. I would rather export it in a file from the /etc/profile.d/ 
directory. The profile.d file should be delivered by a golang package that 
is required to run go programs.







Regards,

Jakub


-- Původní zpráva --
Od: Jakub Cajka 
Komu: jfi...@fedoraproject.org
Datum: 13. 12. 2016 19:07:41
Předmět: Re: F26 System Wide Change: Golang 1.8

"



- Original Message -
> From: jfi...@fedoraproject.org
> To: jca...@redhat.com
> Cc: devel-annou...@lists.fedoraproject.org, "Development discussions 
related to Fedora"
> 
> Sent: Tuesday, December 13, 2016 6:17:23 AM
> Subject: Re: F26 System Wide Change: Golang 1.8
> 
> 
> Jakub,
> 
> 
> 
> 
> can we enable coredumping for Go programs by default - i.e. set 
GOTRACEBACK=
> crash?
> 
> 
> 
> 
> Currently, Go terminate  a process that panic and prints out an error
> message on stderr.
> 
> This approach does not provide much room for automatic Go panic detection.
> 
> 

It should be possible without any significant side effects apart from 
generating cores and traces. But to enable this, I believe, it would need 
alteration to the default system env. Would it be possible? What is the 
package providing the default env vars?

JC

> 
> 
> 
> 
> 
> 
> 
> 
> Regards,
> 
> Jakub
> 
> ABRT
> 
> 
> 
> 
> 
> -- Původní zpráva --
> Od: Jan Kurik 
> Komu: Development discussions related to Fedora  org>, devel-annou...@lists.fedoraproject.org
> Datum: 12. 12. 2016 12:32:15
> Předmět: F26 System Wide Change: Golang 1.8
> 
> "= Proposed System Wide Change: Golang 1.8 =
> https://fedoraproject.org/wiki/Changes/golang1.8
> 
> Change owner(s):
> * Jakub Čajka 
> 
> Rebase of Golang package to upcoming version 1.8 in Fedora 26,
> including rebuild of all dependent packages.
> 
> 
> == Detailed Description ==
> Rebase of Golang package to upcoming version 1.8 in Fedora 26. Golang
> 1.8 is schedule to be released in Feb. Due to current nature of Go
> packages, rebuild of dependent package will be required to pick up the
> changes.
> 
> 
> == Scope ==
> * Proposal owners:
> Rebase golang package in f26, help with resolving possible issues
> found during package rebuilds.
> 
> * Other developers:
> fix possible issues
> 
> * Release engineering:
> As there is scheduled mass-rebuild, nothing should be required.
> 
> * List of deliverables: N/A
> 
> * Policies and guidelines: N/A
> 
> * Trademark approval: N/A
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave@lists.fedoraproject.
org
> "
___
devel mailing list -- devel@lists.fedoraproject.org
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

Re: CVE-2016-8655, systemd, and Fedora

[Rahul Sundaram]

Hi

On Tue, Dec 13, 2016 at 12:00 PM Lennart Poettering
> Well, some of them are pretty drastic. For example, I think it would

> make a ton of sense to run all daemons where that's possible with
> ProtectSystem=strict. This would make the entire directory tree
> read-only for them (with the exception of API VFS, i.e. /proc, /sys,
> /dev), and then requires ReadWritePaths= to be used to whitelist the
> select few paths the service shall be able to write to.
>
> If we'd globally say that all services now run with
> ProtectSystem=strict by default, then we'd break pretty much all
> services that want to write something anywhere, until they get updated
> with the right ReadWritePaths= statements... And I have the suspicion
> that this kind of churn would upset quite a few people... I mean, I am
> all for breaking eggs to make an omelette, but not maybe not break all
> eggs in the egg carton at once ;-)


I am not sure anyone is suggesting breaking things.  There is a pretty
incremental approach to this which starts off with encouraging services to
whitelist things they need and when enough services do that,  toggle the
equivalent sandboxing feature by default and increase coverage over time.
If it requires every service to understand all the sandboxing features and
enable it manually, we aren't getting security features by default and we
really should.

Rahul
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Randy Barlow]

On Mon, 2016-12-12 at 14:33 -0700, Kevin Fenzi wrote:
> First, I'll note you don't need to get a new ticket every day, you
> can
> just renew with 'kinit -R'. I am not sure what env kinit needs, but
> you
> may even be able to do this from a cron job. That will work for 1
> week. 

You can even use systemd timers to do it! You can make these files:

[rbarlow@ohm ~]$ cat ~/.config/systemd/user/kinit-R.service 
[Unit]
Description=Renew Kerberos ticket

[Service]
ExecStart=/usr/bin/kinit -R
Type=oneshot

[Install]
WantedBy=default.target
[rbarlow@ohm ~]$ cat ~/.config/systemd/user/kinit-R.timer 
[Unit]
Description=Renew Kerberos ticket every four hours

[Timer]
OnBootSec=15min
OnUnitActiveSec=4h

[Install]
WantedBy=timers.target

Then you need to enable the timer:

$ systemctl --user enable kinit-R.timer

Hope that helps!

signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[389-devel] Please review: Various tickets

[William Brown]

https://fedorahosted.org/389/ticket/49041

https://fedorahosted.org/389/ticket/49066

https://fedorahosted.org/389/ticket/48835


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane


signature.asc
Description: This is a digitally signed message part
___
389-devel mailing list -- 389-devel@lists.fedoraproject.org
To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org

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

[updates]

The following Fedora EPEL 7 Security updates need testing:
 Age  URL
 646  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-1087   
dokuwiki-0-0.24.20140929c.el7
 408  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-dac7ed832f   
mcollective-2.8.4-1.el7
 127  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-23fa04bf1c   
redis-3.2.3-1.el7
 110  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e8f4ff76b3   
chicken-4.11.0-3.el7
  53  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-ee3cc4d1b6   
compat-guile18-1.8.8-14.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0e9b9b02bb   
phpMyAdmin-4.4.15.9-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-89c47c50a3   
mingw-gdk-pixbuf-2.30.8-2.el7 mingw-qt5-qtimageformats-5.6.0-2.el7 
mingw-jasper-1.900.28-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-bd288eeb9f   
php-php-gettext-1.0.12-1.el7
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-7059e6dc35   
roundcubemail-1.1.7-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-fd41ef0987   
php-simplesamlphp-saml2-2.3.3-1.el7 php-simplesamlphp-saml2_1-1.10.3-1.el7
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-967040283d   
lxc-1.0.9-1.el7
   0  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-090cbd0a83   
botan-1.10.14-3.el7


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

dpm-dsi-1.9.11-1.el7
fedpkg-1.26-3.el7
future-0.16.0-2.el7
opendmarc-1.3.2-0.8.el7
php-horde-Horde-Service-Weather-2.5.3-1.el7
python-ansible-tower-cli-3.0.2-1.el7
python-pyvmomi-6.5-1.el7
python-wcwidth-0.1.7-1.el7
python3-idna-2.1-1.el7
rpkg-1.47-5.el7
xlockmore-5.49-2.el7

Details about builds:



 dpm-dsi-1.9.11-1.el7 (FEDORA-EPEL-2016-61e3b78689)
 Disk Pool Manager (DPM) plugin for the Globus GridFTP server

Update Information:

* new upstream release




 fedpkg-1.26-3.el7 (FEDORA-EPEL-2016-14415f0f51)
 Fedora utility for working with dist-git

Update Information:

This build contains changes needed for flag day on December 12.  - Once you use
this version to upload new sources, older versions of `fedpkg` will not be able
to work with the package.  - pkgs and lookaside site URL are changed. The new
URL uses ``https``. You can see the new URls with ``-d`` and ``-v`` when
``clone`` and ``sources``.  Changelog  - rpkg,
https://pagure.io/rpkg/blob/master/f/CHANGELOG.rst  - fedpkg,
https://pagure.io/fedpkg/blob/master/f/CHANGELOG.rst

References:

  [ 1 ] Bug #714726 - change --root option to --mock-config to fedpkg mockbuild
https://bugzilla.redhat.com/show_bug.cgi?id=714726
  [ 2 ] Bug #841516 - fedpkg scratch-build error message should be improved to 
tell you how to do a scratch build without pushing
https://bugzilla.redhat.com/show_bug.cgi?id=841516
  [ 3 ] Bug #1325775 - Working on branch without remote tracking branch fails 
due to unpushed changes
https://bugzilla.redhat.com/show_bug.cgi?id=1325775
  [ 4 ] Bug #1203757 - The description of fedpkg verify-files in the man page 
and help text is misleading
https://bugzilla.redhat.com/show_bug.cgi?id=1203757
  [ 5 ] Bug #1169663 - Build stops with "Could not execute scratch_build: There 
are unpushed changes in your repo" when there are no unpushed changes in the 
current branch
https://bugzilla.redhat.com/show_bug.cgi?id=1169663
  [ 6 ] Bug #1402882 - fedpkg local fails
https://bugzilla.redhat.com/show_bug.cgi?id=1402882




 future-0.16.0-2.el7 (FEDORA-EPEL-2016-67b5a912d4)
 Easy, clean, reliable Python 2/3 compatibility

Update Information:

- Update to 0.16.0




 opendmarc-1.3.2-0.8.el7 (FEDORA-EPEL-2016-61b2a31c65)
 A Domain-based Message Authentication, Reporting & Conformance (DMARC) milter 
and library

Update Information:

This update fixes a bug that would cause opendmarc to crash soon after starting
up. See [RHBZ 

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

[updates]

The following Fedora EPEL 6 Security updates need testing:
 Age  URL
 524  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7031   
python-virtualenv-12.0.7-1.el6
 518  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-7168   
rubygem-crack-0.3.2-2.el6
 450  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-8156   
nagios-4.0.8-1.el6
 408  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-e2b4b5b2fb   
mcollective-2.8.4-1.el6
 380  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-35e240edd9   
thttpd-2.25b-24.el6
 110  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8594ed3a53   
chicken-4.11.0-3.el6
  50  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-cb5398893b   
nodejs-0.10.48-3.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-0018ee705f   
phpMyAdmin-4.0.10.18-1.el6
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-63073e2e01   
php-php-gettext-1.0.12-1.el6
  12  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-93771e981d   
tomcat-7.0.73-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-8482adf875   
php-simplesamlphp-saml2-2.3.3-1.el6 php-simplesamlphp-saml2_1-1.10.3-1.el6
   9  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-5ddfd80ad5   
lxc-1.0.9-1.el6
   7  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-851b04cffd   
golang-1.7.4-1.el6


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

asio-1.10.8-1.el6
dpm-dsi-1.9.11-1.el6
fedora-packager-0.6.0.0-1.el6
fedpkg-minimal-1.1.0-7.el6
future-0.16.0-2.el6
inxi-2.3.5-2.el6
ioping-1.0-1.el6
koji-1.11.0-1.el6
opendmarc-1.3.2-0.8.el6
php-horde-Horde-Service-Weather-2.5.3-1.el6
python-ansible-tower-cli-3.0.2-1.el6
python-cccolutils-1.5-1.el6
python-wcwidth-0.1.7-1.el6
python3-idna-2.1-1.el6

Details about builds:



 asio-1.10.8-1.el6 (FEDORA-EPEL-2016-b45ad19525)
 A cross-platform C++ library for network programming

Update Information:

update

References:

  [ 1 ] Bug #1396638 - asio FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1396638




 dpm-dsi-1.9.11-1.el6 (FEDORA-EPEL-2016-fb2f5a4066)
 Disk Pool Manager (DPM) plugin for the Globus GridFTP server

Update Information:

* new upstream release




 fedora-packager-0.6.0.0-1.el6 (FEDORA-EPEL-2016-08d67cbaf8)
 Tools for setting up a fedora maintainer environment

Update Information:

Updates needed for the fedora infra flag day 2016




 fedpkg-minimal-1.1.0-7.el6 (FEDORA-EPEL-2016-b480677247)
 Script to allow fedpkg fetch to work

Update Information:

needed to fix building with flag day changes    updates needed for new
sources format    This update provides handling for the new sources format
created as part of the flag day changes.




 future-0.16.0-2.el6 (FEDORA-EPEL-2016-0c48bec554)
 Easy, clean, reliable Python 2/3 compatibility

Update Information:

- Update to 0.16.0




 inxi-2.3.5-2.el6 (FEDORA-EPEL-2016-60330b7393)
 A full featured system information script

Update Information:

Corrected unresolved deps: /usr/bin/bash.    Update to 2.3.5.




 ioping-1.0-1.el6 (FEDORA-EPEL-2016-19e5a15091)
 Simple disk I/O latency monitoring tool

Update Information:

Update

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

[updates]

The following Fedora EPEL 5 Security updates need testing:
 Age  URL
 765  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2014-3849   
sblim-sfcb-1.3.8-2.el5
 408  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-edbea40516   
mcollective-2.8.4-1.el5
 380  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-582c8075e6   
thttpd-2.25b-24.el5
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-e172bd9393   
phpMyAdmin4-4.0.10.18-1.el5
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-d99f990696   
php-php-gettext-1.0.12-1.el5
  13  https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-88041bbead   
php53-php-gettext-1.0.12-1.el5


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

asio-1.10.8-1.el5
fedpkg-minimal-1.1.0-7.el5

Details about builds:



 asio-1.10.8-1.el5 (FEDORA-EPEL-2016-4e15fbcbc6)
 A cross-platform C++ library for network programming

Update Information:

update

References:

  [ 1 ] Bug #1396638 - asio FTBFS
https://bugzilla.redhat.com/show_bug.cgi?id=1396638




 fedpkg-minimal-1.1.0-7.el5 (FEDORA-EPEL-2016-53c6f69eb9)
 Script to allow fedpkg fetch to work

Update Information:

needed to fix building with flag day changes    updates needed for new
sources format

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 13, 2016 at 09:10:46PM +0100, Lennart Poettering wrote:
> On Tue, 13.12.16 15:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:
> 
> > On 12/13/2016 02:51 PM, Lennart Poettering wrote:
> > > Yeah, this is really what it boils down to: the goal with the systemd
> > > directives is to make things easy to grok and easy to change. I can
> > > probably explain to most Linux admins who have administered a current
> > > Fedora in 5min what ProtectSystem=strict and
> > > ReadWritePaths=/var/lib/myservice does, and why it's a good thing. And
> > 
> > One thing that SELinux does right is auditing---access violations are
> > logged, so that there are no silent mysterious failures (well, mumble,
> > mumble, maybe sometimes, you know what I mean). Also, SELinux allows
> > debugging in the permissive mode that just logs without actually blocking
> > access. What happens after systemd directives result in denials?
> 
> There's no auditing hook-up with systemd's sandboxing options.
> 
> The precise error your service gets depends on the sandboxing setting:
> ProtectSystem=strict makes file systems read-only for a service, and
> hence will result in EROFS if it tries to access something.

The expand on this a bit: because of the way those features are
implemented (remounting swatches of the file system tree read-only),
there's no magic, and no special auditing is necessary: the program
gets a normal error (EROFS, EACESS, etc), and should log and handle it
in the usual manner. In case this is not enough, strace will do a good job.
In many ways, this is easier an more flexible than audit logs.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1397130] Upgrade perl-Data-Validate-IP to 0.27

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #2 from Fedora Update System  ---
perl-Data-Validate-IP-0.27-1.fc25 has been pushed to the Fedora 25 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-2016-8bf43bfafe

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

[Bug 1396861] perl-SNMP-Info-3.34 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-SNMP-Info-3.34-1.fc25 has been pushed to the Fedora 25 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-2016-569d2b803a

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

[Bug 1404061] perl-TeX-Hyphen-1.18 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|MODIFIED|ON_QA



--- Comment #6 from Fedora Update System  ---
perl-TeX-Hyphen-1.18-1.fc25 has been pushed to the Fedora 25 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-2016-7213cdf529

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

Re: Two more concrete ideas for what a once-yearly+update schedule would look like

[Matthew Miller]

On Fri, Dec 09, 2016 at 12:12:56PM -0800, Adam Williamson wrote:
> > What if we combined this time threshold with, also, auto-pushes happen
> > only on Monday (or whatever)?
> I wouldn't hate it. On a visceral level I've never bought the 'batched
> updates' idea at all, but if it only affects autopushes I don't mind
> tweaking around. It doesn't involve too much work to change, it's easy
> to change back, and manual pushes are still available.

I submitted these ideas as Bodhi RFEs:

https://github.com/fedora-infra/bodhi/issues/1156
https://github.com/fedora-infra/bodhi/issues/1157


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 831716] Bugzilla requires perl-JSON-RPC-CGI for JSON-RPC functionality which checksetup.pl does not warn about

[bugzilla]

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



--- Comment #24 from Fedora Update System  ---
bugzilla-4.4.12-2.fc23 has been pushed to the Fedora 23 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

[EPEL-devel] Re: Fwd: Interested in joining EPEL SIG

[Dominik 'Rathann' Mierzejewski]

Hello, Beth, and welcome.

On Thursday, 08 December 2016 at 21:25, Beth Lynn Eicher wrote:
> Hello,
> 
> I am interested in joining the EPEL SIG. If I am in the wrong place, please
> inform me.

This is the right place. There's also the #epel IRC channel. There's a
wiki page at https://fedoraproject.org/wiki/EPEL_Package_Maintainers .
If there's anything unclear, please ask.

> To be more specific, I am interested in helping in any of the following
> areas:
> 1. Identify any packages in need of ownership.
> 2. Volunteer to own orphaned packages and/or take on packages that ought to
> be a part of EPEL and are not already.
> 3. Communicate with the modularity efforts in Fedora.
> 4. Keep the CentOS community updated regarding EPEL.
> 5. Attend IRC meetings specific to the EPEL SIG. If these don't exist, I am
> willing to coordinate.

There are weekly meetings on Tuesdays at 18:00 UTC.

> 6. EPEL QA
> 7. Wiki gardening EPEL related pages.
> 8. Anything else?!?
> 
> Please let me know if there is anything else that I can do to get involved
> with EPEL.

That's a pretty long list and it'd be awesome if you were able to help
ith even half of that.

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

[Bug 1404493] New: perl-Math-BigInt-1.999806 is available

[bugzilla]

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

Bug ID: 1404493
   Summary: perl-Math-BigInt-1.999806 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Math-BigInt
  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.999806
Current version/release in rawhide: 1.9998.05-1.fc26
URL: http://search.cpan.org/dist/Math-BigInt/

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/7954/

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

[Bug 1404491] New: perl-App-cpm-0.294 is available

[bugzilla]

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

Bug ID: 1404491
   Summary: perl-App-cpm-0.294 is available
   Product: Fedora
   Version: rawhide
 Component: perl-App-cpm
  Keywords: FutureFeature, Triaged
  Assignee: jples...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org



Latest upstream release: 0.294
Current version/release in rawhide: 0.293-1.fc26
URL: http://search.cpan.org/dist/App-cpm/

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/8399/

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

Re: Haskell packaging issue: dnf reports "nothing provides ghc()"

[Eric Smith]

On Tue, Dec 13, 2016 at 4:38 PM, Orion Poplawski 
wrote:

> Actually, you do need some more BuildRequires:
> but I can't reproduce your ghc() issue on EL7 or F25.


Thanks for looking at it! With your suggested BuildRequires, scratch builds
on Koji succeed for both F24 and F25, but the resulting F24 RPM has the
same broken ghc() dependency as my local build. Since there's no reason
that it needs to be built for F24, I'll only plan on pushing updates for
F25 and EPEL7.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1404486] New: perl-Clownfish-CFC-0.6.1 is available

[bugzilla]

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

Bug ID: 1404486
   Summary: perl-Clownfish-CFC-0.6.1 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Clownfish-CFC
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: jples...@redhat.com,
perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.6.1
Current version/release in rawhide: 0.6.0.5-1.fc26
URL: http://search.cpan.org/dist/Clownfish-CFC/

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/7506/

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

[Bug 1404485] New: perl-Clownfish-0.6.1 is available

[bugzilla]

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

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



Latest upstream release: 0.6.1
Current version/release in rawhide: 0.6.0.5-1.fc26
URL: http://search.cpan.org/dist/Clownfish/

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/7511/

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

Re: Gdm set both Desktop and laptop to an X session on Current fedora 25 Workstation.

[Timothy Ward]

On Tue, 2016-12-13 at 13:25 -0800, Adam Williamson wrote:
> On Wed, 2016-12-14 at 08:20 +1100, Timothy Ward wrote:
> > Is there a current problem with gdm setting a X session or Wayland
> > session as on login with Gdm setting Gnome or Gnome on Xorg still
> > ends
> > in an X session.
> > 
> > Confirmed from the process list that an X session is set even if
> > Gnome
> >  
> > is selected in gdm. 
> > 
> > I am sure I tested after upgrade to F25 and it worked then.
> 
> It will fall back to X automatically in various circumstances. We'd
> need logs, I guess, to figure out exactly what's going on in your
> case.

This is one area I have no T/S experience in.

I uploaded a small gdm debug log to http://pastebin.com/raw/t9tur3QU
for info

If any other logs are required please let me know what logs and the
best way to get them. - command line switches etc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Haskell packaging issue: dnf reports "nothing provides ghc()"

[Orion Poplawski]

On 12/13/2016 03:52 PM, Eric Smith wrote:
> I'm trying to package BNFC, a Haskell program to translate labelled BNF
> grammars to lexer and parser specifications for common lexer and parser
> generators (Alex, JLex, Flex, Happy, CUP, and Bison). I've tried to follow the
> Haskell packaging guidelines. My package builds locally, and if I install it
> with "rpm -Uvh --nodeps" it works fine.
> 
> However, trying to install it normally with dnf reports:
> Error: nothing provides ghc() needed by bnfc-2.8.1-1.fc24.x86_64
> 
> Are the ghc rpm macros causing a problem due to my package not actually
> requiring any other ghc packages to be installed?
> 
> I've put my current spec and SRPM at:
> https://fedorapeople.org/~brouhaha/bnfc/bnfc.spec
> https://fedorapeople.org/~brouhaha/bnfc/bnfc-2.8.1-1.fc24.src.rpm
> 
> I am very much a novice with Haskell. I've only just started working through
> "Haskell Programming from first principles".

Actually, you do need some more BuildRequires:

alex
happy
ghc-mtl-devel

but I can't reproduce your ghc() issue on EL7 or F25.

-- 
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1389064] EPEL7 branch missing (required for psad)

[bugzilla]

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

Dominik 'Rathann' Mierzejewski  changed:

   What|Removed |Added

 CC||admil...@redhat.com
  Flags||needinfo?(admiller@redhat.c
   ||om)



--- Comment #2 from Dominik 'Rathann' Mierzejewski  ---
Adam, you're the maintainer of the EPEL7 branch, but there are no builds. Could
you build this for EPEL7?

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

[Bug 1389060] EPEL7 branch missing (required for psad)

[bugzilla]

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

Dominik 'Rathann' Mierzejewski  changed:

   What|Removed |Added

  Flags||needinfo?(tremble@tremble.o
   ||rg.uk)



--- Comment #2 from Dominik 'Rathann' Mierzejewski  ---
Mark, I can see you're (co-)maintainer of EL5/6 branches. Would you be
interested in maintaining the EPEL7 branch?

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

Re: F26 System Wide Change: Enable coredumpctl by default

[Dominik 'Rathann' Mierzejewski]

On Monday, 12 December 2016 at 20:54, Nicholas Miell wrote:
[...]
> systemd-coredump (or, rather, journald) ignores the split between system
> accounts and user accounts as configured in /etc/login.defs ("the
> authoritative definition of UID/GID space allocation", according to the
> Fedora wiki) and instead hard codes 1000 as the split*.
> 
> The end result is that when systemd-coredump enabled, unprivileged users
> cannot access their own core dumps. (Or any of their own logs in journald.)
> 
> This means that if you are a loyal Fedora user that initially installed
> before the change from 500 to 1000 (Fedora 15 or earlier) and have been
> faithfully upgrading from release to release, enabling systemd-coredump by
> default in Fedora 26 will be a regression in functionality.
> 
> systemd-coredump should not be enabled by default in Fedora until this bug
> is fixed by the systemd developers.
> 
> *: It's actually more egregious than that: /etc/login.defs is parsed on the
> build machine at compile time and the extracted value is hard coded into the
> various systemd executables which then completely ignore /etc/login.defs at
> run time.

Have you filed a bug (preferably upstream)? If yes, please share the bug
number and comment in the FESCo ticket (https://pagure.io/fesco/issue/1654).

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1401295] perl-Net-GitHub-0.86 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

   Fixed In Version|perl-Net-GitHub-0.86-1.fc25 |perl-Net-GitHub-0.86-1.fc25
   ||perl-Net-GitHub-0.86-1.fc24



--- Comment #6 from Fedora Update System  ---
perl-Net-GitHub-0.86-1.fc24 has been pushed to the Fedora 24 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

Haskell packaging issue: dnf reports "nothing provides ghc()"

[Eric Smith]

I'm trying to package BNFC, a Haskell program to translate labelled BNF
grammars to lexer and parser specifications for common lexer and parser
generators (Alex, JLex, Flex, Happy, CUP, and Bison). I've tried to follow
the Haskell packaging guidelines. My package builds locally, and if I
install it with "rpm -Uvh --nodeps" it works fine.

However, trying to install it normally with dnf reports:
Error: nothing provides ghc() needed by bnfc-2.8.1-1.fc24.x86_64

Are the ghc rpm macros causing a problem due to my package not actually
requiring any other ghc packages to be installed?

I've put my current spec and SRPM at:
https://fedorapeople.org/~brouhaha/bnfc/bnfc.spec
https://fedorapeople.org/~brouhaha/bnfc/bnfc-2.8.1-1.fc24.src.rpm

I am very much a novice with Haskell. I've only just started working
through "Haskell Programming from first principles".
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Announcement: Fedora Docker Layered Image Build Service is GO!

[Adam Miller]

On Tue, Dec 13, 2016 at 2:52 PM, Igor Gnatenko  wrote:
> On Tue, Dec 13, 2016 at 8:36 PM, Adam Miller
>  wrote:
>> It is with great pleasure that the Fedora Project Announces the availability
>> of the Fedora Docker Layered Image Build Service[0] to the Fedora Contributor
>> Community!
>>
>> With this announcement we are opening availability of the Docker Layered
>> Image Build Service for the Docker Layered Images[1] that the Fedora Cloud
>> SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as
>> official components of Fedora. From there we will be extending an invitation
>> to all Fedora Contributors to maintain Docker Layered Image Containers for
>> official release by the Fedora Project. Currently this effort is to enable
>> the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a
>> primary deliverable to power the future of Cloud. This is also to enable the
>> Fedora Modularity[5] work be delivered as Containers in the future as Fedora
>> becomes fundamentally more modular in nature.
>>
>> How do I get started?
>>
>> Contributors will go through a simliar process as what they currently do
>> with RPM Review Requests. There will be Container Reviews as well as
>> Container Guidelines:
>>
>> https://fedoraproject.org/wiki/Container:Review_Process
>> https://fedoraproject.org/wiki/Container:Guidelines
> Nice job!
>
> I have couple of questions:
> * why "FROM fedora:25", how do I choose version on which I want to
> base container?

The 'FROM fedora:25' line should coordinate with the branch of DistGit
you're working in. Since Docker doesn't have a mechanism like RPMs do
with macros where we can parameterize things like that, we just have
to define it for now (we may later change it to where the 'FROM
fedora:$version' is inferred and something makes a modification to the
Dockerfile before building.

> * is there containers in registry for rawhide?

There are not at this moment, only for Fedora 24 and Fedora 25. I hope
to have rawhide enabled very soon though. The layout of DistGit
branches correlated to Fedora release information fed into the Build
System is something that needs be sorted since "branched" Fedora
Releases have a version number tied to DistGit but Rawhide is
technically f26 right now. I'll update as soon as this is live.

-AdamM

>>
>> At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as
>> the Review Process along with input from all Fedora Contributors. This may
>> change later with the formation of a Fedora Container Committee (similar to
>> the Fedora Packaging Committee[6]).
>>
>> Please note that both the Guidelines and the Review Process are likely to
>> evolve along with the Container technologies as we move into the future so
>> we encourage community members to check the documentation for updates.
>>
>> For more information, please see the following Fedora Community Blog:
>>
>> 
>> https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/
>>
>> [0] - 
>> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
>> [1] - https://fedoraproject.org/wiki/Cloud
>> [2] - 
>> https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
>> [3] - https://github.com/fedora-cloud/Fedora-Dockerfiles
>> [4] - https://getfedora.org/en/atomic/download/
>> [5] - https://fedoraproject.org/wiki/Modularity
>> [6] - https://fedoraproject.org/wiki/Packaging_Committee
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
>
>
> --
> -Igor Gnatenko
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> 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

Re: Packagers - Flag day 2016 Important changes

[Tom Hughes]

On 13/12/16 21:32, Simo Sorce wrote:

On Tue, 2016-12-13 at 18:52 +, Tom Hughes wrote:


The main goal of long random passwords after all is about a combination
of making them hard to brute force and ensuring that every service has a
unique password to guard against credential reuse attacks when one of
the many services everybody has logins for experiences the inevitable
loss of their poorly secured database.

I always find it somewhat depressing that the more sophisticated a login
system becomes the worse my security on it seems to get because I wind
up having to use weaker passwords. Banks are the classic example because
they rarely have a straightforward password even as one part of their
authentication but anything that means I have to remember a password
hits the same problem.


Don't remember it if it bothers you, why do you use a double standard if
the password is not sent via browser but through a CLI ?


It's an interesting question, and the first thing I'd say is that there 
are actually very few passwords that I enter at a CLI at all. Once I've 
unlocked gnome keyring by logging into my laptop or desktop it's mostly 
only when I want to sudo as other things tend to be by ssh public key 
auth from my keyring.


I think the threat model is very different as well, at least for me, as 
the environments where I am entering a password for sudo for example are 
all ones which I control and where I know how the password database is 
stored while for web based logins I operate on the basis that I have no 
idea whether any given site has the sense to hash it's passwords or to 
adequately protect it's user database.


Obviously I'm sure the FAS database is properly protected but the ways 
of working I have developed are based around not assuming that for web 
logins hence why I switched to random passwords and a password manager 
many years ago.


Anyway, it looks like like GOA with the realmd fix likely does what I 
want, which is good news.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[David Woodhouse]

On Sun, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote:
> All package maintainers will want to make sure they have updated to
> the 
> following package versions (some may be in testing as of this email):
> 
>  python-cccolutils-1.4-1
>  fedpkg-1.26-2
>  fedora-packager-0.6.0.0-1
>  pyrpkg-1.47-3
>  koji-1.11.0-1

[dwoodhou@i7 master]$ rpm -q python3-cccolutils fedpkg fedora-packager pyrpkg 
koji
python3-cccolutils-1.4-1.fc25.x86_64
fedpkg-1.26-2.fc26.noarch
fedora-packager-0.6.0.0-1.fc25.noarch
pyrpkg-1.47-3.fc26.noarch
koji-1.11.0-1.fc25.noarch
[dwoodhou@i7 master]$ fedpkg -vd build
Creating repo object from /home/dwmw2/fedora/openconnect/master
Your git configuration does not use a namespace.
Consider updating your git configuration by running:
Could not read Fedora cert, falling back to default method: !!!cannot read 
your ~/.fedora.cert file   !!!
!!! Ensure the file is readable and try again !!!
  git remote set-url origin 
ssh://dwood...@pkgs.fedoraproject.org/rpms/openconnect
Initiating a koji session to https://koji.fedoraproject.org/kojihub
Could not execute build: (-1765328370, 'KDC has no support for encryption type')
Traceback (most recent call last):
  File "/usr/bin/fedpkg", line 16, in 
main()
  File "/usr/lib/python2.7/site-packages/fedpkg/__main__.py", line 77, in main
sys.exit(client.args.command())
  File "/usr/lib/python2.7/site-packages/pyrpkg/cli.py", line 988, in build
sets, nvr_check)
  File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 1877, in 
build
build_target = self.kojisession.getBuildTarget(self.target)
  File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 216, in 
kojisession
self.load_kojisession()
  File "/usr/lib/python2.7/site-packages/fedpkg/__init__.py", line 314, in 
load_kojisession
return super(Commands, self).load_kojisession(anon)
  File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 378, in 
load_kojisession
self.login_koji_session(koji_config, self._kojisession)
  File "/usr/lib/python2.7/site-packages/pyrpkg/__init__.py", line 345, in 
login_koji_session
session.krb_login(proxyuser=self.runas)
  File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2087, in 
krb_login
options=krbV.AP_OPTS_MUTUAL_REQUIRED)
krbV.Krb5Error: (-1765328370, 'KDC has no support for encryption type')
[dwoodhou@i7 master]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_500
Default principal: dw...@fedoraproject.org

Valid starting ExpiresService principal
13/12/16 12:40:44  14/12/16 12:40:41  krbtgt/fedoraproject@fedoraproject.org
renew until 20/12/16 12:40:41, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
13/12/16 13:09:10  14/12/16 12:40:41  HTTP/proxy10.fedoraproject.org@
renew until 20/12/16 12:40:41, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
13/12/16 13:09:10  14/12/16 12:40:41  
HTTP/proxy10.fedoraproject@fedoraproject.org
renew until 20/12/16 12:40:41, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
13/12/16 16:47:51  14/12/16 12:40:41  HTTP/proxy01.fedoraproject.org@
renew until 20/12/16 12:40:41, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
13/12/16 16:47:51  14/12/16 12:40:41  
HTTP/proxy01.fedoraproject@fedoraproject.org
renew until 20/12/16 12:40:41, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
13/12/16 16:47:52  14/12/16 12:40:41  
host/koji.fedoraproject@fedoraproject.org
renew until 20/12/16 12:40:41, Etype (skey, tkt): 
aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Simo Sorce]

On Tue, 2016-12-13 at 18:52 +, Tom Hughes wrote:
> On 13/12/16 18:19, Simo Sorce wrote:
> > On Tue, 2016-12-13 at 14:36 +, Dave Love wrote:
> >> Simo Sorce  writes:
> >>
> >>> If you really need to automate it because typing a password is too hard:
> >>> cat ~/.mykrbpassword | kinit myusername
> >>
> >> It needs to be automated principally because the password is not
> >> memorable.  I assume infrastructure people would rather we don't use the
> >> least secure credentials we can.
> >
> > It is the same password you had to use every day to access services like
> > bodhi, pkgdb, fas, etc...
> 
> Yes, the 16 character random one that is known to my browser's password 
> manager but not to me unless I look it up. So yes I do "use" it all the 
> time but only in as much as I hit the login button on my browser's 
> toolbar and it sends it to the web site.
> 
> > Now all those services are kerberized too (via OIDC IDP middleman) so
> > you can just kinit once and then access all those services w/o sending
> > password around, all in all I think it is a better situation.
> 
> Well yes that is probably another option, but it would still have to be 
> a weakened password to stand any chance of being memorable.

If you are ok storing it in the browser then you can store it elsewhere
and pipe it in kinit, I do not see a problem here.

> The main goal of long random passwords after all is about a combination 
> of making them hard to brute force and ensuring that every service has a 
> unique password to guard against credential reuse attacks when one of 
> the many services everybody has logins for experiences the inevitable 
> loss of their poorly secured database.
> 
> I always find it somewhat depressing that the more sophisticated a login 
> system becomes the worse my security on it seems to get because I wind 
> up having to use weaker passwords. Banks are the classic example because 
> they rarely have a straightforward password even as one part of their 
> authentication but anything that means I have to remember a password 
> hits the same problem.

Don't remember it if it bothers you, why do you use a double standard if
the password is not sent via browser but through a CLI ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Gdm set both Desktop and laptop to an X session on Current fedora 25 Workstation.

[Adam Williamson]

On Wed, 2016-12-14 at 08:20 +1100, Timothy Ward wrote:
> Is there a current problem with gdm setting a X session or Wayland
> session as on login with Gdm setting Gnome or Gnome on Xorg still ends
> in an X session.
> 
> Confirmed from the process list that an X session is set even if Gnome
>  
> is selected in gdm. 
> 
> I am sure I tested after upgrade to F25 and it worked then.

It will fall back to X automatically in various circumstances. We'd
need logs, I guess, to figure out exactly what's going on in your case.
-- 
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

Gdm set both Desktop and laptop to an X session on Current fedora 25 Workstation.

[Timothy Ward]

Is there a current problem with gdm setting a X session or Wayland
session as on login with Gdm setting Gnome or Gnome on Xorg still ends
in an X session.

Confirmed from the process list that an X session is set even if Gnome
 
is selected in gdm. 

I am sure I tested after upgrade to F25 and it worked then.

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

Re: Announcement: Fedora Docker Layered Image Build Service is GO!

[Igor Gnatenko]

On Tue, Dec 13, 2016 at 8:36 PM, Adam Miller
 wrote:
> It is with great pleasure that the Fedora Project Announces the availability
> of the Fedora Docker Layered Image Build Service[0] to the Fedora Contributor
> Community!
>
> With this announcement we are opening availability of the Docker Layered
> Image Build Service for the Docker Layered Images[1] that the Fedora Cloud
> SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as
> official components of Fedora. From there we will be extending an invitation
> to all Fedora Contributors to maintain Docker Layered Image Containers for
> official release by the Fedora Project. Currently this effort is to enable
> the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a
> primary deliverable to power the future of Cloud. This is also to enable the
> Fedora Modularity[5] work be delivered as Containers in the future as Fedora
> becomes fundamentally more modular in nature.
>
> How do I get started?
>
> Contributors will go through a simliar process as what they currently do
> with RPM Review Requests. There will be Container Reviews as well as
> Container Guidelines:
>
> https://fedoraproject.org/wiki/Container:Review_Process
> https://fedoraproject.org/wiki/Container:Guidelines
Nice job!

I have couple of questions:
* why "FROM fedora:25", how do I choose version on which I want to
base container?
* is there containers in registry for rawhide?
>
> At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as
> the Review Process along with input from all Fedora Contributors. This may
> change later with the formation of a Fedora Container Committee (similar to
> the Fedora Packaging Committee[6]).
>
> Please note that both the Guidelines and the Review Process are likely to
> evolve along with the Container technologies as we move into the future so
> we encourage community members to check the documentation for updates.
>
> For more information, please see the following Fedora Community Blog:
>
> 
> https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/
>
> [0] - 
> https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
> [1] - https://fedoraproject.org/wiki/Cloud
> [2] - 
> https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
> [3] - https://github.com/fedora-cloud/Fedora-Dockerfiles
> [4] - https://getfedora.org/en/atomic/download/
> [5] - https://fedoraproject.org/wiki/Modularity
> [6] - https://fedoraproject.org/wiki/Packaging_Committee
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
-Igor Gnatenko
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Un-retiring QCad

[John Florian]

On Tue, 2016-12-13 at 19:45 +0100, Kevin Kofler wrote:

Przemek Klosowski wrote:


The reason why I'm asking is that I believe that in general FOSS
projects should fork as little as possible, and merge as much as
possible, to avoid duplication of effort. There are circumstances where
the fork is the only solution, of course, and I am asking what are the
circumstances in this case.



In this case, it looks like they forked because of the totally closed
development structure of the upstream project and its unwillingness to port
from Qt 3 to Qt 4. By now, we are in Qt 5 era, and the projects have
diverged so much that a merger is highly unlikely.


I haven't followed the fork -- I didn't even realize it existed until this 
thread -- I stayed with upstream, even buying a license for a few years. While 
it'd be nice to see it move along to a newer Qt, I've been very impressed with 
the feature additions since it became closed and open again. I'm equally 
unimpressed with his build processes; one glaring example is 
http://www.qcad.org/bugtracker/index.php?do=details_id=1369. I started 
packaging it for myself just to work around such issues.

So I'm curious, has the fork maintained any sort of feature parity? Did it 
adopt Qt 4 or 5? If not, I'd much prefer to see the upstream product make it 
back to Fedora. If the fork does use a newer Qt but hasn't progressed much 
feature-wise then I don't know what to think of the situation other than it 
sucks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1401295] perl-Net-GitHub-0.86 is available

[bugzilla]

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

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version||perl-Net-GitHub-0.86-1.fc25
 Resolution|--- |ERRATA
Last Closed||2016-12-13 15:27:36



--- Comment #5 from Fedora Update System  ---
perl-Net-GitHub-0.86-1.fc25 has been pushed to the Fedora 25 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

Re: CVE-2016-8655, systemd, and Fedora

[Tom Hughes]

On 13/12/16 20:02, Przemek Klosowski wrote:

On 12/13/2016 02:51 PM, Lennart Poettering wrote:

Yeah, this is really what it boils down to: the goal with the systemd
directives is to make things easy to grok and easy to change. I can
probably explain to most Linux admins who have administered a current
Fedora in 5min what ProtectSystem=strict and
ReadWritePaths=/var/lib/myservice does, and why it's a good thing. And


One thing that SELinux does right is auditing---access violations are
logged, so that there are no silent mysterious failures (well, mumble,
mumble, maybe sometimes, you know what I mean). Also, SELinux allows
debugging in the permissive mode that just logs without actually
blocking access. What happens after systemd directives result in denials?


There speaks the person that has never had something blocked by a 
noaudit rule in the selinux policy...


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Start packaging/maintaining in Fedora

[Przemek Klosowski]

On 12/13/2016 03:00 PM, Ms Sanchez wrote:


To be honest I looked at wikis and so, but I'm still rather confused, 
I don't know really where or how to start. Why do I want to start 
packaging?  Well, I want to keep contributing to Fedora but more into 
development. As I know programming languages but I'm not too 
experienced I think starting with packaging and/or maintaining 
something small will fit better my skills.
Your approach  (offering a link in Gnome Software when a program is 
missing) would be great, I think.
The ultimate article describing packaging is 
https://fedoraproject.org/wiki/How_to_create_an_RPM_package . It is very 
comprehensive, at a risk of being overwhelming.
I felt a smaller, more digestible hands-on project would be a good 
introduction to packaging. It's like a self-paced lab that you can do on 
your own computer in few hours:

https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_packagen
I hope you like it, and if you do, perhaps I could persuade you to help 
me update it: I thought adding an internationalization support would be 
a nice follow-on, and perhaps a section on using fedpkg and Fedora 
infrastructure.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Lennart Poettering]

On Tue, 13.12.16 15:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:

> On 12/13/2016 02:51 PM, Lennart Poettering wrote:
> > Yeah, this is really what it boils down to: the goal with the systemd
> > directives is to make things easy to grok and easy to change. I can
> > probably explain to most Linux admins who have administered a current
> > Fedora in 5min what ProtectSystem=strict and
> > ReadWritePaths=/var/lib/myservice does, and why it's a good thing. And
> 
> One thing that SELinux does right is auditing---access violations are
> logged, so that there are no silent mysterious failures (well, mumble,
> mumble, maybe sometimes, you know what I mean). Also, SELinux allows
> debugging in the permissive mode that just logs without actually blocking
> access. What happens after systemd directives result in denials?

There's no auditing hook-up with systemd's sandboxing options.

The precise error your service gets depends on the sandboxing setting:
ProtectSystem=strict makes file systems read-only for a service, and
hence will result in EROFS if it tries to access something.

The seccomp-based settings by default result in EPERM.

> BTW, it's ProtectSystem=true/false/full (not strict), right?

ProtectSystem=strict is a v232 addition (→ rawhide). It's stricter
than "full" even...

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Przemek Klosowski]

On 12/13/2016 02:51 PM, Lennart Poettering wrote:

Yeah, this is really what it boils down to: the goal with the systemd
directives is to make things easy to grok and easy to change. I can
probably explain to most Linux admins who have administered a current
Fedora in 5min what ProtectSystem=strict and
ReadWritePaths=/var/lib/myservice does, and why it's a good thing. And


One thing that SELinux does right is auditing---access violations are 
logged, so that there are no silent mysterious failures (well, mumble,  
mumble, maybe sometimes, you know what I mean). Also, SELinux allows 
debugging in the permissive mode that just logs without actually 
blocking access. What happens after systemd directives result in denials?


BTW, it's ProtectSystem=true/false/full (not strict), right?

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

Re: Start packaging/maintaining in Fedora

[Ms Sanchez]

On 12/12/16 13:38, Vít Ondruch wrote:


Hi Sylvia,

Just wondering, what were the places you were looking at to find the 
information how to start maintaining package in Fedora. Or what is the 
reason you want to package something into Fedora.


I am asking, since there are various ongoing activities to make the 
process easier to newcomers [1], but unfortunately, they are not 
always successful. So would it be for example helpful, if 
gnome-software shown some link with help how to package the missing 
software, e.g.


1) Open Gnome Software

2) Sear for "myfavoriteapp"

3) The link [2] is provided instead of "Application was not found" 
message.


Would this help or just make you confused? Would the similar approach 
for Fedora packages [3] helped? Is there some other place you were 
looking at which long time Fedora package does not visit, but newcomer 
does?



Vít



[1] https://fedoraproject.org/wiki/Fedora_Join_SIG

[2] https://fedoraproject.org/wiki/Join_the_package_collection_maintainers

[3] https://apps.fedoraproject.org/packages





Hello!

To be honest I looked at wikis and so, but I'm still rather confused, I 
don't know really where or how to start. Why do I want to start 
packaging?  Well, I want to keep contributing to Fedora but more into 
development. As I know programming languages but I'm not too experienced 
I think starting with packaging and/or maintaining something small will 
fit better my skills.
Your approach  (offering a link in Gnome Software when a program is 
missing) would be great, I think.


Cheers,
Sylvia

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

Re: Packages up for grabs

[Adam Williamson]

On Tue, 2016-12-13 at 20:56 +0100, Dan Horák wrote:
> On Mon, 12 Dec 2016 15:33:33 -0800
> Adam Williamson  wrote:
> 
> > On Mon, 2016-12-12 at 10:22 -0800, Brian C. Lane wrote:
> > > In the spirit of the season I'm giving away packages :)
> > > 
> > > I am not using most of these anymore, so I'd like to send them off
> > > to a good home:
> > > 
> > > https://admin.fedoraproject.org/pkgdb/packager/bcl/ All the
> > > python-* packages, plus pylint, docker-anaconda-addon, bip, mx, and
> > > livecd-tools.
> > > 
> > > Let me know which ones you want and I'll give them to you,
> > > otherwise they'll be orphaned by Friday.
> > 
> > I'll take bip at least for now, but I reserve the right to switch to
> > znc or whatever the rest of the world is using and ditch it soon :)
> 
> I use bip, so I'll set myself as co-maintainer

There's a couple of things about it annoying me at present:

https://projects.duckcorp.org/issues/500
https://projects.duckcorp.org/issues/499

We definitely have to fix #499 in order to maintain the package going
forward, and I wasted an afternoon chasing after openssl behaviour to
try and figure out what's going on in #500 to no avail.
-- 
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

Re: Packages up for grabs

[Dan Horák]

On Mon, 12 Dec 2016 15:33:33 -0800
Adam Williamson  wrote:

> On Mon, 2016-12-12 at 10:22 -0800, Brian C. Lane wrote:
> > In the spirit of the season I'm giving away packages :)
> > 
> > I am not using most of these anymore, so I'd like to send them off
> > to a good home:
> > 
> > https://admin.fedoraproject.org/pkgdb/packager/bcl/ All the
> > python-* packages, plus pylint, docker-anaconda-addon, bip, mx, and
> > livecd-tools.
> > 
> > Let me know which ones you want and I'll give them to you,
> > otherwise they'll be orphaned by Friday.
> 
> I'll take bip at least for now, but I reserve the right to switch to
> znc or whatever the rest of the world is using and ditch it soon :)

I use bip, so I'll set myself as co-maintainer


Dan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Lennart Poettering]

On Tue, 13.12.16 14:25, Matthew Miller (mat...@fedoraproject.org) wrote:

> On Tue, Dec 13, 2016 at 10:42:08AM -0800, Japheth Cleaver wrote:
> > >For a less-effort version, we could update
> > >https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
> > >marketing campaign asking people to update their packages (as
> > >suggested, ideally upstream).
> > 
> > I'd much rather that effort be put into good SELinux policy
> > evangelization, documentation, and perhaps additional
> > admin-controllable booleans.
> 
> That takes a lot more specific SELinux expertise — I don't think it's
> likely that the packager of everything that has a .service file in
> Fedora has the SELinux knowledge to do that, while adding these
> restrictions is much more straightforward.

Yeah, this is really what it boils down to: the goal with the systemd
directives is to make things easy to grok and easy to change. I can
probably explain to most Linux admins who have administered a current
Fedora in 5min what ProtectSystem=strict and
ReadWritePaths=/var/lib/myservice does, and why it's a good thing. And
afterwards he can easily add this to his own services. With SELinux
that's not that easy: the concepts are much more complex (at least in
my opinion, but I am sure many will agree), and as the selinux policy
is packaged centrally making a change is not trivially easy to do.

That said, SELinux and the systemd sandboxing directives are very
different concepts. I don't think they are in competition really, and
I am pretty sure everybody would benefit if both the SELinux policy
and the systemd unit files would be improved.

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Alexander Bokovoy]

On ti, 13 joulu 2016, David Woodhouse wrote:

On Mon, 2016-12-12 at 10:53 +0100, Vít Ondruch wrote:

2) I needed to update a certificate every 6 months, now I need to kinit
every day. This is regression. How to make it work without kinit at all.
I am using SSSD for company kerberos and I don't need to kinit at all,
how to make this work for Fedora?


Maybe we could support PKINIT? :)

We just committed first parts of PKINIT support in FreeIPA git master.
I'm not sure Fedora Infrastructure will utilize that any time soon but
we certainly are getting there with upstream FreeIPA. ;)

--
/ Alexander Bokovoy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages up for grabs

[Adam Williamson]

On Tue, 2016-12-13 at 20:19 +0100, Martin Kolman wrote:
> On Mon, 2016-12-12 at 15:34 -0800, Adam Williamson wrote:
> > On Mon, 2016-12-12 at 14:35 -0700, Kevin Fenzi wrote:
> > > 
> > > 
> > > > 
> > > > And then recently it was ported to use DNF, and so it's now
> > > > maintained
> > > > again, or it it?
> > > 
> > > I'll let the folks who worked on that chime in on their plans.
> > > I have no idea. 
> > 
> > AIUI the people who did that work are folks who build a few
> > different Fedora variants and don't like how livemedia-creator works.
> 
> Is the way livemedia-creator that different from livecd-tools ?

Yes, substantially. livecd-creator basically sets up a chroot on the
system it's running on and interprets the live image kickstart itself
to install a bunch of packages and do a bunch of modifications to that
environment, then converts that environment into an image file.

livemedia-creator works by running an anaconda install into an
environment, feeding the kickstart to anaconda rather than interpreting
it itself, and then converting the resulting environment into an image
file. It was originally *intended* that the environment would be a
virtual machine, but that turned out to be fundamentally incompatible
with how Koji works, so lmc now has a '--no-virt' mode where it uses a
fairly new anaconda feature that lets you run an install into a
directory.

>  Or
> harder to use ? 

In a way, it is. With livecd-creator, you can quite easily run an image
build from your regular Fedora system in a way which is virtually
identical to how Koji does/did livecd-creator builds, so what you get
is very similar to an 'official' live image.

It's rather harder to do this with lmc. The way Koji uses lmc is it
sets up a mock chroot, then uses lmc --no-virt within the mock chroot.
If you want to build a live image the same way 'official' Fedora live
images are built, you have to either set up your own Koji deployment
(which is its own whole nest of rats) or recreate this process manually
(or write a script to do it): you have to create a mock chroot, install
the necessary packages into it, copy a flattened kickstart file into
it, then run the compose inside the chroot and get the resulting image
file out of the chroot. It's all possible, and not that hard once
you've done it a couple of times, but it's substantially more of a faff
than just pulling a one-line 'livecd-creator' command out of your
command history.

Your *other* choice is to use lmc's virt mode, which you should be able
to use from your regular desktop without any special preparation.
However, that doesn't work the same way our official image builds work
so it's possible it might somehow behave differently and give you
images with some important difference from the official ones (or just
be broken entirely), and some people have had trouble getting it to
work properly. Including me - every time I've tried to use it, it's
gone wrong somehow (I haven't tried it lately since I figured out how
to use the --no-virt mode in mock, though).

One of the things on my List Of Side Projects To Work On If I Ever Get
Time is a sort of koji-lite wrapper script which would let you run a
single command to do the '--no-virt build in a mock chroot' thing on a
typical  Fedora system, but I've just never got around to it yet.
-- 
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

Announcement: Fedora Docker Layered Image Build Service is GO!

[Adam Miller]

It is with great pleasure that the Fedora Project Announces the availability
of the Fedora Docker Layered Image Build Service[0] to the Fedora Contributor
Community!

With this announcement we are opening availability of the Docker Layered
Image Build Service for the Docker Layered Images[1] that the Fedora Cloud
SIG[2] has been the primary maintainers[3] of on GitHub into DistGit as
official components of Fedora. From there we will be extending an invitation
to all Fedora Contributors to maintain Docker Layered Image Containers for
official release by the Fedora Project. Currently this effort is to enable
the Fedora Cloud/Atomic WG[2] goals which target Fedora Atomic Host[4] as a
primary deliverable to power the future of Cloud. This is also to enable the
Fedora Modularity[5] work be delivered as Containers in the future as Fedora
becomes fundamentally more modular in nature.

How do I get started?

Contributors will go through a simliar process as what they currently do
with RPM Review Requests. There will be Container Reviews as well as
Container Guidelines:

https://fedoraproject.org/wiki/Container:Review_Process
https://fedoraproject.org/wiki/Container:Guidelines

At this time the Cloud/Atomic WG[2] will maintain the Guidelines as well as
the Review Process along with input from all Fedora Contributors. This may
change later with the formation of a Fedora Container Committee (similar to
the Fedora Packaging Committee[6]).

Please note that both the Guidelines and the Review Process are likely to
evolve along with the Container technologies as we move into the future so
we encourage community members to check the documentation for updates.

For more information, please see the following Fedora Community Blog:


https://communityblog.fedoraproject.org/fedora-docker-layered-image-build-service-now-available/

[0] - https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service
[1] - https://fedoraproject.org/wiki/Cloud
[2] - 
https://docs.docker.com/engine/userguide/storagedriver/imagesandcontainers/
[3] - https://github.com/fedora-cloud/Fedora-Dockerfiles
[4] - https://getfedora.org/en/atomic/download/
[5] - https://fedoraproject.org/wiki/Modularity
[6] - https://fedoraproject.org/wiki/Packaging_Committee
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Matthew Miller]

On Tue, Dec 13, 2016 at 10:42:08AM -0800, Japheth Cleaver wrote:
> >For a less-effort version, we could update
> >https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
> >marketing campaign asking people to update their packages (as
> >suggested, ideally upstream).
> 
> I'd much rather that effort be put into good SELinux policy
> evangelization, documentation, and perhaps additional
> admin-controllable booleans.

That takes a lot more specific SELinux expertise — I don't think it's
likely that the packager of everything that has a .service file in
Fedora has the SELinux knowledge to do that, while adding these
restrictions is much more straightforward.

(I mean, if you or anyone else want to help with that *too*, awesome.)

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages up for grabs

[Martin Kolman]

On Mon, 2016-12-12 at 15:34 -0800, Adam Williamson wrote:
> On Mon, 2016-12-12 at 14:35 -0700, Kevin Fenzi wrote:
> > 
> > 
> > > 
> > > And then recently it was ported to use DNF, and so it's now
> > > maintained
> > > again, or it it?
> > 
> > I'll let the folks who worked on that chime in on their plans.
> > I have no idea. 
> 
> AIUI the people who did that work are folks who build a few
> different Fedora variants and don't like how livemedia-creator works.
Is the way livemedia-creator that different from livecd-tools ? Or
harder to use ? 

I just wonder why porting livecd-tool from yum to dnf and basically
taking over it maintenance was chosen instead of adding the
(presumably) missing functionality to livemedia-creator and using that
instead.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Tom Hughes]

On 13/12/16 18:19, Simo Sorce wrote:

On Tue, 2016-12-13 at 14:36 +, Dave Love wrote:

Simo Sorce  writes:


If you really need to automate it because typing a password is too hard:
cat ~/.mykrbpassword | kinit myusername


It needs to be automated principally because the password is not
memorable.  I assume infrastructure people would rather we don't use the
least secure credentials we can.


It is the same password you had to use every day to access services like
bodhi, pkgdb, fas, etc...


Yes, the 16 character random one that is known to my browser's password 
manager but not to me unless I look it up. So yes I do "use" it all the 
time but only in as much as I hit the login button on my browser's 
toolbar and it sends it to the web site.



Now all those services are kerberized too (via OIDC IDP middleman) so
you can just kinit once and then access all those services w/o sending
password around, all in all I think it is a better situation.


Well yes that is probably another option, but it would still have to be 
a weakened password to stand any chance of being memorable.


The main goal of long random passwords after all is about a combination 
of making them hard to brute force and ensuring that every service has a 
unique password to guard against credential reuse attacks when one of 
the many services everybody has logins for experiences the inevitable 
loss of their poorly secured database.


I always find it somewhat depressing that the more sophisticated a login 
system becomes the worse my security on it seems to get because I wind 
up having to use weaker passwords. Banks are the classic example because 
they rarely have a straightforward password even as one part of their 
authentication but anything that means I have to remember a password 
hits the same problem.


Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packages up for grabs

[Kevin Kofler]

Adam Williamson wrote:
> AIUI the people who did that work are folks who build a few
> different Fedora variants

… and Mageia too (Neal Gompa and Angelo Naselli have a Mageia port) …

> and don't like how livemedia-creator works.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Un-retiring QCad

[Kevin Kofler]

Przemek Klosowski wrote:
> The reason why I'm asking is that I believe that in general FOSS
> projects should fork as little as possible, and merge as much as
> possible, to avoid duplication of effort. There are circumstances where
> the fork is the only solution, of course, and I am asking what are the
> circumstances in this case.

In this case, it looks like they forked because of the totally closed 
development structure of the upstream project and its unwillingness to port 
from Qt 3 to Qt 4. By now, we are in Qt 5 era, and the projects have 
diverged so much that a merger is highly unlikely.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Japheth Cleaver]

On 12/13/2016 7:00 AM, Matthew Miller wrote:

On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote:

Well, the security policies need to be adapted to the service in
question, hence a blanket switch to enable all of them for every
service is problematic. Let's say you block gettimeofday()
system-wide, but then run an NTP service: you just broke it...

I fear it's too late to turn on all sandboxing options by default for
regular services. If we would have had them back when we started we
of course would have made them opt-out rather than opt-in, but that's
too late now...

I'm not so sure it's too late, if we would publicize the change well
enough in advance and have some proven packagers dedicated to finding
any exceptions. It's a matter of how much priority we put on
preventative security measures.

For a less-effort version, we could update
https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
marketing campaign asking people to update their packages (as
suggested, ideally upstream).



I'd much rather that effort be put into good SELinux policy 
evangelization, documentation, and perhaps additional admin-controllable 
booleans.


-jc
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Golang 1.8

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 13, 2016 at 01:06:29PM -0500, Jakub Cajka wrote:
> > can we enable coredumping for Go programs by default - i.e. set GOTRACEBACK=
> > crash?
> > 
> > Currently, Go terminate  a process that panic and prints out an error
> > message on stderr.
> > 
> > This approach does not provide much room for automatic Go panic detection.
> 
> It should be possible without any significant side effects apart from 
> generating cores and traces. But to enable this, I believe, it would need 
> alteration to the default system env. 

Would it be possible? What is the package providing the default env vars?

systemd has DefaultEnvironment= in /etc/systemd/system.conf, but it is
supposed to be used to create local overrides, and doesn't work well
for this case (it's %config(noreplace) among other problems). In general
setting global env vars does not work.

Instead, it would be nicer to modify the go runtime to default to a coredump
if GOTRACEBACK= is not set. This would cover more cases and would not pollute
the environment for users who are not using go.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Simo Sorce]

On Tue, 2016-12-13 at 14:35 +, Dave Love wrote:
> Simo Sorce  writes:
> 
> > On Tue, 2016-12-13 at 10:54 +, Dave Love wrote:
> >> Kevin Fenzi  writes:
> >> 
> >> > This is included in the fedora-packager-0.6.0 update. 
> >> >
> >> > Make sure your /etc/krb5.conf has the include to include them
> >> > from /etc/krb5.conf.d/ though
> >> 
> >> That will break Heimdal, for people who use that.
> >
> > Heimdal is not packaged in Fedora,
> 
> It clearly is, and I have the package installed.
> 
> > if you care for compiling and using
> > it yourself I am sure you can change the default ccache scheme as well.
> >
> > Simo.
> 
> Oh, please.  The above was nothing to do with ccache anyhow.  (I don't
> know how it works currently, but Samba4 used to be based on Heimdal, and
> I thought inherited that sort of thing.  When I last worked on it,
> krb5.conf was meant to be interchangeable.)

The krb5.conf is interchangeable if you use a subset of directives
common to both, this directive is not common to both, therefore it is
incompatible with Heimdal.
Samba has been ported to MIT Kerberos for Fedora uses, and the ability
to support more advanced ccaches was one of the reasons.

> I did actually ask about Heimdal initially.

Sorry but we do not use Heimdal in the distro so I do not see why that
would be a concern.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Simo Sorce]

On Tue, 2016-12-13 at 14:36 +, Dave Love wrote:
> Simo Sorce  writes:
> 
> > If you really need to automate it because typing a password is too hard:
> > cat ~/.mykrbpassword | kinit myusername
> 
> It needs to be automated principally because the password is not
> memorable.  I assume infrastructure people would rather we don't use the
> least secure credentials we can.

It is the same password you had to use every day to access services like
bodhi, pkgdb, fas, etc...
Now all those services are kerberized too (via OIDC IDP middleman) so
you can just kinit once and then access all those services w/o sending
password around, all in all I think it is a better situation.

> There is actually a Kerberos mechanism for storing credentials even if
> it somewhat defeats the object, particularly on a shared system.  It
> would be better if you could forward the GSS identities over ssh, but I
> don't see that you can.

You can if you authenticate with such an identity, but you can't forward
additional identities indeed.
But I am not sure why you would need to forward your user credentials to
servers normally. Did you copy your certs everywhere before ? I would
think the normal case is that people have 1 development machine where
they handle packaging.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: missing credentials

[Howard Howell]

On Tue, 2016-12-13 at 09:44 +0100, Milan Crha wrote:
> On Mon, 2016-12-12 at 12:43 -0600, Michael Catanzaro wrote:
> > That sounds highly plausible. evolution currently shells out to gpg
> > which is pretty fragile, so it's not very surprising that some
> > issue
> > could cause it to hang forever. It needs to be rewritten to use
> > GPGME.
> 
>   Hi,
> I looked on GPGME sometime in the beginning of the year and it's
> missing some features the evolution(-data-server) uses. I do not
> recaal
> what exactly, I'm sorry. It's still just a front end for the gpg/ggp2
> binary, thus basically the same what the evolution-data-server does.
> 
> These things are run in a dedicated thread, thus they do not block
> the
> UI, only may result in an infinite wait for a response from the
> gpg/gpg2. It doesn't result in a timeout though. Being it about
> gpg/gpg2, I'd reference:
> https://bugzilla.gnome.org/show_bug.cgi?id=769204
> 
> Being it about WebKit2 usage as such (the 3.22.x uses WebKit2, while
> 3.20.x used WebKit1), I'd reference for example:
> https://bugzilla.redhat.com/show_bug.cgi?id=1398806#c2
> 
>   Hope it helps,
>   Milan

The first one GNOME Bugzilla – Bug 769204 says:
Status: RESOLVED NOTGNOME

The second one  Bug 1398806 - Weird rendering for Evolution on
Wayland doesn't seem to apply.

In the past when evolution blocked on gpg messages it was because I
didn't have the correct url to the cert for the sig or encryption. 
could that still be the case here?

I have also noticed that now when I click reply, and then minimize the
evolution window, the reply no longer is interactive.  This is new
behavior with F25 because I could do that with all prior versions of
fedora.  But I suspect that some interaction with wayland/evolution is
the issue.

Regards,
Les H

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

Re: F26 System Wide Change: Golang 1.8

[Jakub Cajka]

- Original Message -
> From: jfi...@fedoraproject.org
> To: jca...@redhat.com
> Cc: devel-annou...@lists.fedoraproject.org, "Development discussions related 
> to Fedora"
> 
> Sent: Tuesday, December 13, 2016 6:17:23 AM
> Subject: Re: F26 System Wide Change: Golang 1.8
> 
> 
> Jakub,
> 
> 
> 
> 
> can we enable coredumping for Go programs by default - i.e. set GOTRACEBACK=
> crash?
> 
> 
> 
> 
> Currently, Go terminate  a process that panic and prints out an error
> message on stderr.
> 
> This approach does not provide much room for automatic Go panic detection.
> 
> 

It should be possible without any significant side effects apart from 
generating cores and traces. But to enable this, I believe, it would need 
alteration to the default system env. Would it be possible? What is the package 
providing the default env vars?

JC

> 
> 
> 
> 
> 
> 
> 
> 
> Regards,
> 
> Jakub
> 
> ABRT
> 
> 
> 
> 
> 
> -- Původní zpráva --
> Od: Jan Kurik 
> Komu: Development discussions related to Fedora  org>, devel-annou...@lists.fedoraproject.org
> Datum: 12. 12. 2016 12:32:15
> Předmět: F26 System Wide Change: Golang 1.8
> 
> "= Proposed System Wide Change: Golang 1.8 =
> https://fedoraproject.org/wiki/Changes/golang1.8
> 
> Change owner(s):
> * Jakub Čajka 
> 
> Rebase of Golang package to upcoming version 1.8 in Fedora 26,
> including rebuild of all dependent packages.
> 
> 
> == Detailed Description ==
> Rebase of Golang package to upcoming version 1.8 in Fedora 26. Golang
> 1.8 is schedule to be released in Feb. Due to current nature of Go
> packages, rebuild of dependent package will be required to pick up the
> changes.
> 
> 
> == Scope ==
> * Proposal owners:
> Rebase golang package in f26, help with resolving possible issues
> found during package rebuilds.
> 
> * Other developers:
> fix possible issues
> 
> * Release engineering:
> As there is scheduled mass-rebuild, nothing should be required.
> 
> * List of deliverables: N/A
> 
> * Policies and guidelines: N/A
> 
> * Trademark approval: N/A
> --
> Jan Kuřík
> Platform & Fedora Program Manager
> Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org
> "
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[EPEL-devel] [Fedocal] Reminder meeting : EPSCO meeting

[smooge]

Dear all,

You are kindly invited to the meeting:
   EPSCO meeting on 2016-12-14 from 18:00:00 to 19:00:00 GMT
   At fedora-meet...@irc.freenode.net

The meeting will be about:
Extra Packages for Enterprise Linux Steering COmmittee (EPSCO) has a weekly 
meeting to go over concerns and problems in the EPEL distribution. 

You are kindly invited to come and meet with us


Source: https://apps.fedoraproject.org/calendar/meeting/4639/

___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Sérgio Basto]

On Ter, 2016-12-13 at 10:37 -0700, Kevin Fenzi wrote:
> On Tue, 13 Dec 2016 17:09:19 +
> Sérgio Basto  wrote:
> 
> > 
> > On Dom, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote:
> > > 
> > > 
> > > Greetings. 
> > > 
> > > As previously announced, releng has made a number of changes as
> > > part
> > > of
> > > it's 2016 "flag day". 
> > > 
> > > All package maintainers will want to make sure they have updated
> > > to
> > > the 
> > > following package versions (some may be in testing as of this
> > > email):
> > > 
> > >  python-cccolutils-1.4-1
> > >  fedpkg-1.26-2
> > >  fedora-packager-0.6.0.0-1
> > >  pyrpkg-1.47-3
> > >  koji-1.11.0-1  
> > I'd like have this tools on F23 , which is not EOL , 
> but will be in less than a week. 
> 
> We decided to concentrate on those branches that will be around and
> supported for a while. We are still fixing various things in epel and
> I
> imagine it would be similar work to try and get f23 working, which we
> don't really have the cycles for. 
> 
> Please upgrade. 
> 
> > 
> > koji -d --debug-xmlrpc download-build -a x86_64 kernel-4.8.14-
> > 100.fc23
> > 
> > 016-12-13 16:25:05,845 [DEBUG] koji: Traceback (most recent call
> > last): File "/usr/lib/python2.7/site-packages/koji/__init__.py",
> > line
> > 2099, in _callMethod
> > return self._sendCall(handler, headers, request)
> >   File "/usr/lib/python2.7/site-packages/koji/__init__.py", line
> > 2010,
> > in _sendCall
> > return self._sendOneCall(handler, headers, request)
> >   File "/usr/lib/python2.7/site-packages/koji/__init__.py", line
> > 2032,
> > in _sendOneCall
> > ret = self._read_xmlrpc_response(response, handler)
> >   File "/usr/lib/python2.7/site-packages/koji/__init__.py", line
> > 2064,
> > in _read_xmlrpc_response
> > response.status, response.reason, response.msg)
> > ProtocolError:  > 302
> > Found>  
> > 
> > download-build shouldn't need authentication ... 
> Thats not authentication, thats because the older koji used http and
> the new one always uses https and tries to redirect you to https if
> you pass it http. You _may_ be able to fix this by
> editing /etc/koji.conf and making all the urls https 

yes , it works .

Thanks for the support. 

> kevin
> 
> 
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.

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

Re: Packagers - Flag day 2016 Important changes

[Kevin Fenzi]

On Tue, 13 Dec 2016 17:09:19 +
Sérgio Basto  wrote:

> On Dom, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote:
> > 
> > Greetings. 
> > 
> > As previously announced, releng has made a number of changes as part
> > of
> > it's 2016 "flag day". 
> > 
> > All package maintainers will want to make sure they have updated to
> > the 
> > following package versions (some may be in testing as of this
> > email):
> > 
> >  python-cccolutils-1.4-1
> >  fedpkg-1.26-2
> >  fedora-packager-0.6.0.0-1
> >  pyrpkg-1.47-3
> >  koji-1.11.0-1  
> 
> I'd like have this tools on F23 , which is not EOL , 

but will be in less than a week. 

We decided to concentrate on those branches that will be around and
supported for a while. We are still fixing various things in epel and I
imagine it would be similar work to try and get f23 working, which we
don't really have the cycles for. 

Please upgrade. 

> koji -d --debug-xmlrpc download-build -a x86_64 kernel-4.8.14-100.fc23
> 
> 016-12-13 16:25:05,845 [DEBUG] koji: Traceback (most recent call
> last): File "/usr/lib/python2.7/site-packages/koji/__init__.py", line
> 2099, in _callMethod
> return self._sendCall(handler, headers, request)
>   File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2010,
> in _sendCall
> return self._sendOneCall(handler, headers, request)
>   File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2032,
> in _sendOneCall
> ret = self._read_xmlrpc_response(response, handler)
>   File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2064,
> in _read_xmlrpc_response
> response.status, response.reason, response.msg)
> ProtocolError:  Found>  
> 
> download-build shouldn't need authentication ... 

Thats not authentication, thats because the older koji used http and
the new one always uses https and tries to redirect you to https if
you pass it http. You _may_ be able to fix this by
editing /etc/koji.conf and making all the urls https 

kevin




pgpoBJEql7qym.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Kevin Fenzi]

On Tue, 13 Dec 2016 10:58:16 +
Dave Love  wrote:

> Kevin Fenzi  writes:
> 
> > Ah, the actual package produced is python2-cccolutils (from the
> > python-cccolutils package). 
> >
> > python2-cccolutils.x86_64 1.4-1.el6 epel-testing  
> 
> Isn't that wrong for EPEL?

No. There's nothing saying a python-foo package has to produce a
python-foo package. 

kevin


pgpGeMkp1AaXs.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Kevin Fenzi]

On Tue, 13 Dec 2016 14:19:50 +
Tom Hughes  wrote:

> On 13/12/16 13:41, Stephen Gallagher wrote:
> > On 12/13/2016 03:52 AM, Vít Ondruch wrote:  
> >>
> >> Dne 12.12.2016 v 22:33 Kevin Fenzi napsal(a):
> >>  
> >>> As sgallagh noted downthread, gnome online accounts will hopefully
> >>> handle this for you soon as soon as that one bug is fixed.  
> >>
> >> That should be fixed prior such changes are pushed. If it is not,
> >> there should be at least somebody pushing this forward.  
> >
> > It was an oversight, which I only discovered a few days before the
> > flag day. A patch was immediately worked up and was expected to be
> > ready in time, which is why I didn't suggest postponing the flag
> > day.  
> 
> Actually it was discussed on IRC on 20th November and I gathered a 
> realmd log demonstrating it and it was supposed to be being looked
> into as I understood things at the time.
> 
> I should probably have filed a bug but at the time I wasn't sure if
> it was an issue with GOA or a configuration issue with the fedora
> kerberos servers.

If someone is assembling a list of blame, feel free to add me to it. 

I noticed this when we were testing in staging, but due to the 1000
other things I was trying to test and get going I didn't file a bug on
it. 

That said, I don't think this is productive. Several of us could have
filed a bug. We didn't. We can try and do better. Lets move on and get
things working with what we have now. 

kevin



pgpbX4wn0xQUV.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Kevin Fenzi]

On Tue, 13 Dec 2016 14:36:06 +
Dave Love  wrote:

> Simo Sorce  writes:
> 
> > If you really need to automate it because typing a password is too
> > hard: cat ~/.mykrbpassword | kinit myusername  
> 
> It needs to be automated principally because the password is not
> memorable.  I assume infrastructure people would rather we don't use
> the least secure credentials we can.

I can't speak for others, but the thought of putting your fas password
in plain text in some start up file makes me cry. I cannot of course
tell anyone what to do, but I can beg you not to do this. 

kevin


pgpexiSF4ui5C.pgp
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Sérgio Basto]

On Dom, 2016-12-11 at 18:34 -0600, Dennis Gilmore wrote:
> 
> Greetings. 
> 
> As previously announced, releng has made a number of changes as part
> of
> it's 2016 "flag day". 
> 
> All package maintainers will want to make sure they have updated to
> the 
> following package versions (some may be in testing as of this email):
> 
>  python-cccolutils-1.4-1
>  fedpkg-1.26-2
>  fedora-packager-0.6.0.0-1
>  pyrpkg-1.47-3
>  koji-1.11.0-1

I'd like have this tools on F23 , which is not EOL , 

koji -d --debug-xmlrpc download-build -a x86_64 kernel-4.8.14-100.fc23

016-12-13 16:25:05,845 [DEBUG] koji: Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2099,
in _callMethod
return self._sendCall(handler, headers, request)
  File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2010,
in _sendCall
return self._sendOneCall(handler, headers, request)
  File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2032,
in _sendOneCall
ret = self._read_xmlrpc_response(response, handler)
  File "/usr/lib/python2.7/site-packages/koji/__init__.py", line 2064,
in _read_xmlrpc_response
response.status, response.reason, response.msg)
ProtocolError: 

download-build shouldn't need authentication ... 

> 
> Please also see the following links for up to date information: 
> 
> https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016
> 
> The following changes were made:
> 
> * koji and the source lookaside were changed to use kerberos
> authentication
> instead of ssl certificates. All maintainers will need to:
> 
> kinit your-fas-accountn...@fedoraaproject.org
> 
> to get a valid kerberos TGT and be able to authenticate to koji and 
> the lookaside upload cgi. 
> 
> See the general kerberos information at: 
> https://fedoraproject.org/wiki/Infrastructure_kerberos_authentication
> for more details.
> 
> Additionally, via GSSAPI many browsers allow you to seamlessly login 
> to any of our ipsilon using applications simply by clicking on the
> login 
> button ( bodhi, fedorahosted trac, elections, fedocal, mailman3, etc)
> 
> * koji now uses a well known cert for https. 
> 
> * pkgs.fedoraproject.org now redirects to https://src.fedoraproject.o
> rg
>  and 
> that uses a well known cert. Please correct any links you use to use
> https://src.fedoraproject.org for packages spec and patch files. 
> 
> * rawhide builds now land in the f26-pending tag, where they are
> signed
> and then 
> added to the f26 tag for compose in the next rawhide compose. This
> allows 
> rawhide packages to be fully signed as well as a point where
> automated
> QA
> can take place in the future. 
> 
> * packages "sources" files now use sha512 by default instead of md5. 
> You will need the fedpkg update in order to create and use these new
> checksums.
> 
> Questions or concerns as always welcome at #fedora-admin on
> irc.freenode.net
> or tickets at https://pagure.io/fedora-infrastructure. 
> ___
> devel-announce mailing list -- devel-annou...@lists.fedoraproject.org
> To unsubscribe send an email to devel-announce-leave@lists.fedoraproj
> ect.org
-- 
Sérgio M. B.

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

Re: CVE-2016-8655, systemd, and Fedora

[Lennart Poettering]

On Tue, 13.12.16 10:00, Matthew Miller (mat...@fedoraproject.org) wrote:

> On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote:
> > Well, the security policies need to be adapted to the service in
> > question, hence a blanket switch to enable all of them for every
> > service is problematic. Let's say you block gettimeofday()
> > system-wide, but then run an NTP service: you just broke it...
> > 
> > I fear it's too late to turn on all sandboxing options by default for
> > regular services. If we would have had them back when we started we
> > of course would have made them opt-out rather than opt-in, but that's
> > too late now...
> 
> I'm not so sure it's too late, if we would publicize the change well
> enough in advance and have some proven packagers dedicated to finding
> any exceptions. It's a matter of how much priority we put on
> preventative security measures.

Well, some of them are pretty drastic. For example, I think it would
make a ton of sense to run all daemons where that's possible with
ProtectSystem=strict. This would make the entire directory tree
read-only for them (with the exception of API VFS, i.e. /proc, /sys,
/dev), and then requires ReadWritePaths= to be used to whitelist the
select few paths the service shall be able to write to.

If we'd globally say that all services now run with
ProtectSystem=strict by default, then we'd break pretty much all
services that want to write something anywhere, until they get updated
with the right ReadWritePaths= statements... And I have the suspicion
that this kind of churn would upset quite a few people... I mean, I am
all for breaking eggs to make an omelette, but not maybe not break all
eggs in the egg carton at once ;-)

(Also, note that things like ProtectSystem=, PrivateTmp=,
PrivateDevices= aren't suitable for "meta" daemons such as crond or
atd, as these daemon are supposed to run arbitrary user code, and
its hence difficult to know where it makes sense to isolate them and
where not, in particular as file system namespacing related options
generally disconnect the service mount namespace from the host, and
that means /bin/mount invocations done by such cron/at scripts would
never have an effect on the host, but stay limited to the cron/at
services. For such "meta" daemons it hence makes little sense to
enable any sandboxing by default, so we'd have to update them too to
then undo the default again locally.)

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Florian Weimer]

On 12/13/2016 12:17 PM, Lennart Poettering wrote:

On Mon, 12.12.16 21:22, Paul Wouters (p...@nohats.ca) wrote:


that's totally possible, and can be functionality-wise entirely
equivalent. The only difference is: systemd makes all of this
trivially easy to use, by making this a single-line change in a unit
file without involving C hacking.


For us (libreswan) it probably makes less sense to restrict address
family in the daemon. Our daemon just listens to UDP 500/4500, so it
would never be affected by any other kind of address families.


Well, if it creates that UDP socket itself then it needs access to
AF_INET, and AF_INET6 at least. And things like syslog() usually imply
AF_UNIX, hence it would probably be a good idea to add
"RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX" if your service
really needs nothing else. That way the service will lose access to
AF_PACKET, AF_NETLINK, AF_BLUETOOTH, … and everything else.


Proper IPv6 support requires AF_NETLINK, too.

Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Lennart Poettering]

On Tue, 13.12.16 10:52, Przemek Klosowski (przemek.klosow...@nist.gov) wrote:

> On 12/12/2016 04:02 PM, Lennart Poettering wrote:
> > Hmm, yeah, I should probably blog more about all the nice sandboxing
> > features we have now in systemd. There's quite some stuff now we
> > should enable wherever we can. Specifically ProtectSystem=,
> > ProtectHome=, ProtectKernelTunables=, ProtectKernelModules=,
> > ProtectedControlGroups=, PrivateUsers=, PrivateTmp=, PrivateDevices=,
> > PrivateNetwork=, SystemCallFilter=, RestrictAddressFamilies=,
> > RestrictNamespaces=, MemoryDenyWriteExecute=, RestrictRealtime=.
> > 
> > For now, the only docs available for them are the man pages. Not all
> > of them are available on all currently maintained Fedoras, but a good
> > chunk is.
> 
> That wasn't quite easy to find although it does make sense in retrospect:
> 
>   man systemd.exec
> 
> man -k ProtectSystem and man systemd|grep ProtectSystem didn't show anything
> because they don't really index the man pages. While looking for this, I
> came up with a useful technique for combing through man pages: maybe it'll
> be useful to someone:

Try "man 7 systemd.directives":

https://www.freedesktop.org/software/systemd/man/systemd.directives.html

Neat, eh?

Lennart

-- 
Lennart Poettering, Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Dave Love]

Stephen Gallagher  writes:

>> There is actually a Kerberos mechanism for storing credentials even if
>> it somewhat defeats the object, particularly on a shared system.  It
>> would be better if you could forward the GSS identities over ssh, but I
   ^^^

>> don't see that you can.
>
> Of course you can: `ssh -K`. From the manpage:
>
>  -K  Enables GSSAPI-based authentication and forwarding (delegation) 
> of
> GSSAPI credentials to the server.

As far as I could tell, that can only be a single identity (possibly per
host), so no use if you need to use a local realm too.  I've been doing
this stuff longer than most and am doubtless not up-to-date, but I did
check the doc on my (non-Fedora) desktop.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[David Woodhouse]

On Mon, 2016-12-12 at 10:53 +0100, Vít Ondruch wrote:
> 2) I needed to update a certificate every 6 months, now I need to kinit
> every day. This is regression. How to make it work without kinit at all.
> I am using SSSD for company kerberos and I don't need to kinit at all,
> how to make this work for Fedora?

Maybe we could support PKINIT? :)

-- 
dwmw2

smime.p7s
Description: S/MIME cryptographic signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Matthew Miller]

On Tue, Dec 13, 2016 at 03:49:45PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > For a less-effort version, we could update
> > https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
> > marketing campaign asking people to update their packages (as
> > suggested, ideally upstream).
> That would be great.
> 
> This can only be done bottom-up, because usually you need to know some
> program very very well to know what policies can be applied to it
> that will not break not just the default configuration, but any
> reasonable configuration that people might be carrying.

Could you draft a new section for that document? We can then take it to
the FPC.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-Array-Compare (perl-Array-Compare-3.0.0-1.fc26). "Update to 3.0.0 (..more)"

[notifications]

From 3e3f28b811526c1e339ba26f7bfb9d32ba9d359c Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Tue, 13 Dec 2016 16:07:31 +
Subject: Update to 3.0.0

- New upstream release 3.0.0
  - New version to get round dubious decisions in Perl toolchain
---
 perl-Array-Compare.spec | 6 +-
 sources | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/perl-Array-Compare.spec b/perl-Array-Compare.spec
index 464981d..f4548e8 100644
--- a/perl-Array-Compare.spec
+++ b/perl-Array-Compare.spec
@@ -1,5 +1,5 @@
 Name:   perl-Array-Compare
-Version:2.12.2
+Version:3.0.0
 Release:1%{?dist}
 Summary:Perl extension for comparing arrays
 Group:  Development/Libraries
@@ -61,6 +61,10 @@ rm -rf %{buildroot}
 %{_mandir}/man3/Array::Compare.3*
 
 %changelog
+* Tue Dec 13 2016 Paul Howarth  - 3.0.0-1
+- Update to 3.0.0
+  - New version to get round dubious decisions in Perl toolchain
+
 * Thu Dec  8 2016 Paul Howarth  - 2.12.2-1
 - Update to 2.12.2
   - Packaging changes
diff --git a/sources b/sources
index e5fab13..516fed3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a666fe1be9867d52bd18f8773b160087  Array-Compare-v2.12.2.tar.gz
+SHA512 (Array-Compare-v3.0.0.tar.gz) = 
6515aa249b49a04f70f39974e1d1c3f802a1b5d76e3e050aeb47a30cf8a4ac0089378822eb0c0aa15697bef09e49227a13c55d4914489f944c3d2f5cc2b4a692
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Array-Compare.git/commit/?h=perl-Array-Compare-3.0.0-1.fc26=3e3f28b811526c1e339ba26f7bfb9d32ba9d359c
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc pushed to perl-Array-Compare (master). "Update to 3.0.0 (..more)"

[notifications]

From 3e3f28b811526c1e339ba26f7bfb9d32ba9d359c Mon Sep 17 00:00:00 2001
From: Paul Howarth 
Date: Tue, 13 Dec 2016 16:07:31 +
Subject: Update to 3.0.0

- New upstream release 3.0.0
  - New version to get round dubious decisions in Perl toolchain
---
 perl-Array-Compare.spec | 6 +-
 sources | 2 +-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/perl-Array-Compare.spec b/perl-Array-Compare.spec
index 464981d..f4548e8 100644
--- a/perl-Array-Compare.spec
+++ b/perl-Array-Compare.spec
@@ -1,5 +1,5 @@
 Name:   perl-Array-Compare
-Version:2.12.2
+Version:3.0.0
 Release:1%{?dist}
 Summary:Perl extension for comparing arrays
 Group:  Development/Libraries
@@ -61,6 +61,10 @@ rm -rf %{buildroot}
 %{_mandir}/man3/Array::Compare.3*
 
 %changelog
+* Tue Dec 13 2016 Paul Howarth  - 3.0.0-1
+- Update to 3.0.0
+  - New version to get round dubious decisions in Perl toolchain
+
 * Thu Dec  8 2016 Paul Howarth  - 2.12.2-1
 - Update to 2.12.2
   - Packaging changes
diff --git a/sources b/sources
index e5fab13..516fed3 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a666fe1be9867d52bd18f8773b160087  Array-Compare-v2.12.2.tar.gz
+SHA512 (Array-Compare-v3.0.0.tar.gz) = 
6515aa249b49a04f70f39974e1d1c3f802a1b5d76e3e050aeb47a30cf8a4ac0089378822eb0c0aa15697bef09e49227a13c55d4914489f944c3d2f5cc2b4a692
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Array-Compare.git/commit/?h=master=3e3f28b811526c1e339ba26f7bfb9d32ba9d359c
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik uploaded Data-Rmap-0.65.tar.gz for perl-Data-Rmap

[notifications]

1cd5793ffe0ab3de7a324e32c2053a269cf939cdc91161289666b63c470d09f4af6ac0ecbda288650a75f0d4e8a73910edc181cc34549f36f821ad57e629e1fc
  Data-Rmap-0.65.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Data-Rmap/Data-Rmap-0.65.tar.gz/sha512/1cd5793ffe0ab3de7a324e32c2053a269cf939cdc91161289666b63c470d09f4af6ac0ecbda288650a75f0d4e8a73910edc181cc34549f36f821ad57e629e1fc/Data-Rmap-0.65.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

pghmcfc uploaded Array-Compare-v3.0.0.tar.gz for perl-Array-Compare

[notifications]

6515aa249b49a04f70f39974e1d1c3f802a1b5d76e3e050aeb47a30cf8a4ac0089378822eb0c0aa15697bef09e49227a13c55d4914489f944c3d2f5cc2b4a692
  Array-Compare-v3.0.0.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Array-Compare/Array-Compare-v3.0.0.tar.gz/sha512/6515aa249b49a04f70f39974e1d1c3f802a1b5d76e3e050aeb47a30cf8a4ac0089378822eb0c0aa15697bef09e49227a13c55d4914489f944c3d2f5cc2b4a692/Array-Compare-v3.0.0.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Data-Rmap (master). "0.65 bump"

[notifications]

From c090f329956bd67683eaee1aee83ea0035d80393 Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 13 Dec 2016 17:04:04 +0100
Subject: 0.65 bump

---
 .gitignore  |  1 +
 perl-Data-Rmap.spec | 10 --
 sources |  2 +-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/.gitignore b/.gitignore
index a68966c..cae9622 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /Data-Rmap-0.62.tar.gz
 /Data-Rmap-0.64.tar.gz
+/Data-Rmap-0.65.tar.gz
diff --git a/perl-Data-Rmap.spec b/perl-Data-Rmap.spec
index bec374e..1cac934 100644
--- a/perl-Data-Rmap.spec
+++ b/perl-Data-Rmap.spec
@@ -1,20 +1,23 @@
 Name:   perl-Data-Rmap
-Version:0.64
-Release:5%{?dist}
+Version:0.65
+Release:1%{?dist}
 Summary:Recursive map, apply a block to a data structure
 License:GPL+ or Artistic
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/Data-Rmap/
 Source0:
http://www.cpan.org/authors/id/B/BO/BOWMANBS/Data-Rmap-%{version}.tar.gz
 BuildArch:  noarch
+BuildRequires:  perl
 BuildRequires:  perl-generators
 BuildRequires:  perl(Carp)
 BuildRequires:  perl(Data::Dumper)
 BuildRequires:  perl(Exporter)
 BuildRequires:  perl(Module::Build)
 BuildRequires:  perl(Scalar::Util)
+BuildRequires:  perl(strict)
 BuildRequires:  perl(Test::Exception)
 BuildRequires:  perl(Test::More)
+BuildRequires:  perl(warnings)
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
 %description
@@ -45,6 +48,9 @@ perl Build.PL installdirs=vendor
 %{_mandir}/man3/*
 
 %changelog
+* Tue Dec 13 2016 Jitka Plesnikova  - 0.65-1
+- 0.65 bump
+
 * Sun May 15 2016 Jitka Plesnikova  - 0.64-5
 - Perl 5.24 rebuild
 
diff --git a/sources b/sources
index f27932d..aeec166 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-112c9e8b813259a4700815ca66342a78  Data-Rmap-0.64.tar.gz
+SHA512 (Data-Rmap-0.65.tar.gz) = 
1cd5793ffe0ab3de7a324e32c2053a269cf939cdc91161289666b63c470d09f4af6ac0ecbda288650a75f0d4e8a73910edc181cc34549f36f821ad57e629e1fc
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Data-Rmap.git/commit/?h=master=c090f329956bd67683eaee1aee83ea0035d80393
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1397610] perl-Data-Rmap-0.65 is available

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |CLOSED
 CC||jples...@redhat.com
   Fixed In Version||perl-Data-Rmap-0.65-1.fc26
 Resolution|--- |RAWHIDE
Last Closed||2016-12-13 11:05:33



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

Re: CVE-2016-8655, systemd, and Fedora

[Przemek Klosowski]

On 12/12/2016 04:02 PM, Lennart Poettering wrote:

Hmm, yeah, I should probably blog more about all the nice sandboxing
features we have now in systemd. There's quite some stuff now we
should enable wherever we can. Specifically ProtectSystem=,
ProtectHome=, ProtectKernelTunables=, ProtectKernelModules=,
ProtectedControlGroups=, PrivateUsers=, PrivateTmp=, PrivateDevices=,
PrivateNetwork=, SystemCallFilter=, RestrictAddressFamilies=,
RestrictNamespaces=, MemoryDenyWriteExecute=, RestrictRealtime=.

For now, the only docs available for them are the man pages. Not all
of them are available on all currently maintained Fedoras, but a good
chunk is.


That wasn't quite easy to find although it does make sense in retrospect:

  man systemd.exec

man -k ProtectSystem and man systemd|grep ProtectSystem didn't show 
anything because they don't really index the man pages. While looking 
for this, I came up with a useful technique for combing through man 
pages: maybe it'll be useful to someone:


for a in $(man -k systemd | cut -f 1 -d ' ') ; do echo $a; man $a | grep 
ProtectSystem ; done


(the $(man .. cut) combo returns the names of all man pages relevant to 
systemd, and then we grep through their content)



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

Re: CVE-2016-8655, systemd, and Fedora

[Zbigniew Jędrzejewski-Szmek]

On Tue, Dec 13, 2016 at 10:00:10AM -0500, Matthew Miller wrote:
> On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote:
> > Well, the security policies need to be adapted to the service in
> > question, hence a blanket switch to enable all of them for every
> > service is problematic. Let's say you block gettimeofday()
> > system-wide, but then run an NTP service: you just broke it...
> > 
> > I fear it's too late to turn on all sandboxing options by default for
> > regular services. If we would have had them back when we started we
> > of course would have made them opt-out rather than opt-in, but that's
> > too late now...
> 
> I'm not so sure it's too late, if we would publicize the change well
> enough in advance and have some proven packagers dedicated to finding
> any exceptions. It's a matter of how much priority we put on
> preventative security measures.

You have to take into account non-distro services that people have.
Globally disabling certain address families will result in silent and
hard to debug failures.

I don't there's any other way except to enable this one by one for
existing services.

> For a less-effort version, we could update
> https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
> marketing campaign asking people to update their packages (as
> suggested, ideally upstream).
That would be great.

This can only be done bottom-up, because usually you need to know some
program very very well to know what policies can be applied to it
that will not break not just the default configuration, but any
reasonable configuration that people might be carrying.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

jplesnik pushed to perl-Data-Validate-IP (master). "0.27 bump"

[notifications]

From ebdc577756b8554b1a161099a9bb777e322b9cee Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 13 Dec 2016 16:25:48 +0100
Subject: 0.27 bump

---
 .gitignore | 1 +
 perl-Data-Validate-IP.spec | 5 -
 sources| 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 8a42a7f..4095872 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /Data-Validate-IP-0.24.tar.gz
 /Data-Validate-IP-0.25.tar.gz
 /Data-Validate-IP-0.26.tar.gz
+/Data-Validate-IP-0.27.tar.gz
diff --git a/perl-Data-Validate-IP.spec b/perl-Data-Validate-IP.spec
index 5a11508..5153206 100644
--- a/perl-Data-Validate-IP.spec
+++ b/perl-Data-Validate-IP.spec
@@ -1,5 +1,5 @@
 Name:  perl-Data-Validate-IP
-Version:   0.26
+Version:   0.27
 Release:   1%{?dist}
 Summary:   Perl IP address validation routines
 
@@ -62,6 +62,9 @@ make test
 
 
 %changelog
+* Tue Dec 13 2016 Jitka Plesnikova  - 0.27-1
+- 0.27 bump
+
 * Mon Aug 01 2016 Jitka Plesnikova  - 0.26-1
 - 0.26 bump
 
diff --git a/sources b/sources
index 1a17b00..74f1d49 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-db902bd4fc3eafc3b638891caf8196c4  Data-Validate-IP-0.26.tar.gz
+SHA512 (Data-Validate-IP-0.27.tar.gz) = 
5a93f730d53e7adcac4fe5e227b69a44e58cdc94b0081d79978547263095e97c3690c8c6fc6664fc8e4b230ab4c360beda22e6600a3c7abe5e61129ee70553b8
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Data-Validate-IP.git/commit/?h=master=ebdc577756b8554b1a161099a9bb777e322b9cee
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1397130] Upgrade perl-Data-Validate-IP to 0.27

[bugzilla]

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

Jitka Plesnikova  changed:

   What|Removed |Added

 Status|NEW |MODIFIED
 CC||jples...@redhat.com
   Fixed In Version||perl-Data-Validate-IP-0.27-
   ||1.fc26



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

jplesnik uploaded Data-Validate-IP-0.27.tar.gz for perl-Data-Validate-IP

[notifications]

5a93f730d53e7adcac4fe5e227b69a44e58cdc94b0081d79978547263095e97c3690c8c6fc6664fc8e4b230ab4c360beda22e6600a3c7abe5e61129ee70553b8
  Data-Validate-IP-0.27.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Data-Validate-IP/Data-Validate-IP-0.27.tar.gz/sha512/5a93f730d53e7adcac4fe5e227b69a44e58cdc94b0081d79978547263095e97c3690c8c6fc6664fc8e4b230ab4c360beda22e6600a3c7abe5e61129ee70553b8/Data-Validate-IP-0.27.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1397130] Upgrade perl-Data-Validate-IP to 0.27

[bugzilla]

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



--- Comment #1 from Fedora Update System  ---
perl-Data-Validate-IP-0.27-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2016-8bf43bfafe

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

jplesnik pushed to perl-Data-Validate-IP (f25). "0.27 bump"

[notifications]

From 6afd184fee86e01e2972880a711bf082cd06b25b Mon Sep 17 00:00:00 2001
From: Jitka Plesnikova 
Date: Tue, 13 Dec 2016 16:25:48 +0100
Subject: 0.27 bump

---
 .gitignore | 1 +
 perl-Data-Validate-IP.spec | 5 -
 sources| 2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/.gitignore b/.gitignore
index 8a42a7f..4095872 100644
--- a/.gitignore
+++ b/.gitignore
@@ -2,3 +2,4 @@
 /Data-Validate-IP-0.24.tar.gz
 /Data-Validate-IP-0.25.tar.gz
 /Data-Validate-IP-0.26.tar.gz
+/Data-Validate-IP-0.27.tar.gz
diff --git a/perl-Data-Validate-IP.spec b/perl-Data-Validate-IP.spec
index 5a11508..5153206 100644
--- a/perl-Data-Validate-IP.spec
+++ b/perl-Data-Validate-IP.spec
@@ -1,5 +1,5 @@
 Name:  perl-Data-Validate-IP
-Version:   0.26
+Version:   0.27
 Release:   1%{?dist}
 Summary:   Perl IP address validation routines
 
@@ -62,6 +62,9 @@ make test
 
 
 %changelog
+* Tue Dec 13 2016 Jitka Plesnikova  - 0.27-1
+- 0.27 bump
+
 * Mon Aug 01 2016 Jitka Plesnikova  - 0.26-1
 - 0.26 bump
 
diff --git a/sources b/sources
index 1a17b00..74f1d49 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-db902bd4fc3eafc3b638891caf8196c4  Data-Validate-IP-0.26.tar.gz
+SHA512 (Data-Validate-IP-0.27.tar.gz) = 
5a93f730d53e7adcac4fe5e227b69a44e58cdc94b0081d79978547263095e97c3690c8c6fc6664fc8e4b230ab4c360beda22e6600a3c7abe5e61129ee70553b8
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Data-Validate-IP.git/commit/?h=f25=6afd184fee86e01e2972880a711bf082cd06b25b
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: CVE-2016-8655, systemd, and Fedora

[Matthew Miller]

On Tue, Dec 13, 2016 at 12:14:44PM +0100, Lennart Poettering wrote:
> Well, the security policies need to be adapted to the service in
> question, hence a blanket switch to enable all of them for every
> service is problematic. Let's say you block gettimeofday()
> system-wide, but then run an NTP service: you just broke it...
> 
> I fear it's too late to turn on all sandboxing options by default for
> regular services. If we would have had them back when we started we
> of course would have made them opt-out rather than opt-in, but that's
> too late now...

I'm not so sure it's too late, if we would publicize the change well
enough in advance and have some proven packagers dedicated to finding
any exceptions. It's a matter of how much priority we put on
preventative security measures.

For a less-effort version, we could update
https://fedoraproject.org/wiki/Packaging:Systemd and have an (internal)
marketing campaign asking people to update their packages (as
suggested, ideally upstream).

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ignatenkobrain pushed to perl-Text-Hunspell (master). "Rebuild for hunspell 1.5.x (..more)"

[notifications]

From 712150e6dcbdf45976efe7aeb353f0964e87b3c6 Mon Sep 17 00:00:00 2001
From: Igor Gnatenko 
Date: Tue, 13 Dec 2016 15:59:01 +0100
Subject: Rebuild for hunspell 1.5.x

Signed-off-by: Igor Gnatenko 
---
 perl-Text-Hunspell.spec | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/perl-Text-Hunspell.spec b/perl-Text-Hunspell.spec
index 36b502e..14922bd 100644
--- a/perl-Text-Hunspell.spec
+++ b/perl-Text-Hunspell.spec
@@ -1,6 +1,6 @@
 Name:  perl-Text-Hunspell
 Version:   2.14
-Release:   3%{?dist}
+Release:   4%{?dist}
 Summary:   Perl interface to the Hunspell library
 License:   GPL+ or Artistic
 URL:   http://search.cpan.org/dist/text_hunspell/
@@ -64,6 +64,9 @@ LANG=en_US make test TEST_POD=1 TEST_VERBOSE=1
 %{_mandir}/man3/Text::Hunspell.3*
 
 %changelog
+* Tue Dec 13 2016 Igor Gnatenko  - 2.14-4
+- Rebuild for hunspell 1.5.x
+
 * Sun May 15 2016 Jitka Plesnikova  - 2.14-3
 - Perl 5.24 rebuild
 
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Text-Hunspell.git/commit/?h=master=712150e6dcbdf45976efe7aeb353f0964e87b3c6
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-Net-LDAP-Server-Test (f25). "Initial import."

[notifications]

From 39fcfbaca3684053e74fe1d3203c0307dd2f0633 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Tue, 13 Dec 2016 15:47:14 +0100
Subject: Initial import.

---
 .gitignore |  1 +
 perl-Net-LDAP-Server-Test.spec | 73 ++
 sources|  1 +
 3 files changed, 75 insertions(+)
 create mode 100644 perl-Net-LDAP-Server-Test.spec

diff --git a/.gitignore b/.gitignore
index e69de29..439a853 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Net-LDAP-Server-Test-0.22.tar.gz
diff --git a/perl-Net-LDAP-Server-Test.spec b/perl-Net-LDAP-Server-Test.spec
new file mode 100644
index 000..e624176
--- /dev/null
+++ b/perl-Net-LDAP-Server-Test.spec
@@ -0,0 +1,73 @@
+Name:   perl-Net-LDAP-Server-Test
+Version:0.22
+Release:1%{?dist}
+Summary:Test Net::LDAP code
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/Net-LDAP-Server-Test/
+Source0:
http://www.cpan.org/authors/id/K/KA/KARMAN/Net-LDAP-Server-Test-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl >= 0:5.008003
+
+BuildRequires:  perl-generators
+
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(Convert::ASN1)
+BuildRequires:  perl(Data::Dump)
+BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(File::Temp)
+BuildRequires:  perl(IO::Select)
+BuildRequires:  perl(IO::Socket)
+BuildRequires:  perl(IO::Socket::INET)
+BuildRequires:  perl(Net::LDAP)
+BuildRequires:  perl(Net::LDAP::ASN)
+BuildRequires:  perl(Net::LDAP::Constant)
+BuildRequires:  perl(Net::LDAP::Control)
+BuildRequires:  perl(Net::LDAP::Entry)
+BuildRequires:  perl(Net::LDAP::Filter)
+BuildRequires:  perl(Net::LDAP::FilterMatch)
+BuildRequires:  perl(Net::LDAP::LDIF)
+BuildRequires:  perl(Net::LDAP::Server) >= 0.3
+BuildRequires:  perl(Net::LDAP::SID)
+BuildRequires:  perl(Net::LDAP::Util)
+BuildRequires:  perl(Test::More)
+BuildRequires:  perl(base)
+BuildRequires:  perl(constant)
+BuildRequires:  perl(fields)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+
+# Optional
+BuildRequires:  perl(Test::Pod) >= 1.14
+BuildRequires:  perl(Test::Pod::Coverage) >= 1.04
+
+BuildRequires:  %{__make}
+BuildRequires:  %{__perl}
+
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+
+%description
+Test your Net::LDAP code without having a real LDAP server available.
+
+%prep
+%setup -q -n Net-LDAP-Server-Test-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+%{__make} %{?_smp_mflags}
+
+%install
+%{__make} pure_install DESTDIR=$RPM_BUILD_ROOT
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+%{__make} test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Dec 13 2016 Ralf Corsépius  - 0.22-1
+- Initial Fedora package.
diff --git a/sources b/sources
index e69de29..0f46e65 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+SHA512 (Net-LDAP-Server-Test-0.22.tar.gz) = 
d311b83a9941c881eb3e1737a5afac3e29bca536a2c1727d2c08261ce4974ef99e2f7130acc1736f10e1728a12a8a8f21fab6b72d14e1c35e7d2d44e2d1a1be4
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Net-LDAP-Server-Test.git/commit/?h=f25=39fcfbaca3684053e74fe1d3203c0307dd2f0633
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu pushed to perl-Net-LDAP-Server-Test (master). "Initial import."

[notifications]

From 39fcfbaca3684053e74fe1d3203c0307dd2f0633 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ralf=20Cors=C3=A9pius?= 
Date: Tue, 13 Dec 2016 15:47:14 +0100
Subject: Initial import.

---
 .gitignore |  1 +
 perl-Net-LDAP-Server-Test.spec | 73 ++
 sources|  1 +
 3 files changed, 75 insertions(+)
 create mode 100644 perl-Net-LDAP-Server-Test.spec

diff --git a/.gitignore b/.gitignore
index e69de29..439a853 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/Net-LDAP-Server-Test-0.22.tar.gz
diff --git a/perl-Net-LDAP-Server-Test.spec b/perl-Net-LDAP-Server-Test.spec
new file mode 100644
index 000..e624176
--- /dev/null
+++ b/perl-Net-LDAP-Server-Test.spec
@@ -0,0 +1,73 @@
+Name:   perl-Net-LDAP-Server-Test
+Version:0.22
+Release:1%{?dist}
+Summary:Test Net::LDAP code
+License:GPL+ or Artistic
+Group:  Development/Libraries
+URL:http://search.cpan.org/dist/Net-LDAP-Server-Test/
+Source0:
http://www.cpan.org/authors/id/K/KA/KARMAN/Net-LDAP-Server-Test-%{version}.tar.gz
+BuildArch:  noarch
+BuildRequires:  perl >= 0:5.008003
+
+BuildRequires:  perl-generators
+
+BuildRequires:  perl(Carp)
+BuildRequires:  perl(Convert::ASN1)
+BuildRequires:  perl(Data::Dump)
+BuildRequires:  perl(ExtUtils::MakeMaker)
+BuildRequires:  perl(File::Temp)
+BuildRequires:  perl(IO::Select)
+BuildRequires:  perl(IO::Socket)
+BuildRequires:  perl(IO::Socket::INET)
+BuildRequires:  perl(Net::LDAP)
+BuildRequires:  perl(Net::LDAP::ASN)
+BuildRequires:  perl(Net::LDAP::Constant)
+BuildRequires:  perl(Net::LDAP::Control)
+BuildRequires:  perl(Net::LDAP::Entry)
+BuildRequires:  perl(Net::LDAP::Filter)
+BuildRequires:  perl(Net::LDAP::FilterMatch)
+BuildRequires:  perl(Net::LDAP::LDIF)
+BuildRequires:  perl(Net::LDAP::Server) >= 0.3
+BuildRequires:  perl(Net::LDAP::SID)
+BuildRequires:  perl(Net::LDAP::Util)
+BuildRequires:  perl(Test::More)
+BuildRequires:  perl(base)
+BuildRequires:  perl(constant)
+BuildRequires:  perl(fields)
+BuildRequires:  perl(strict)
+BuildRequires:  perl(warnings)
+
+# Optional
+BuildRequires:  perl(Test::Pod) >= 1.14
+BuildRequires:  perl(Test::Pod::Coverage) >= 1.04
+
+BuildRequires:  %{__make}
+BuildRequires:  %{__perl}
+
+Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
+
+%description
+Test your Net::LDAP code without having a real LDAP server available.
+
+%prep
+%setup -q -n Net-LDAP-Server-Test-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor NO_PACKLIST=1
+%{__make} %{?_smp_mflags}
+
+%install
+%{__make} pure_install DESTDIR=$RPM_BUILD_ROOT
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+%{__make} test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Dec 13 2016 Ralf Corsépius  - 0.22-1
+- Initial Fedora package.
diff --git a/sources b/sources
index e69de29..0f46e65 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+SHA512 (Net-LDAP-Server-Test-0.22.tar.gz) = 
d311b83a9941c881eb3e1737a5afac3e29bca536a2c1727d2c08261ce4974ef99e2f7130acc1736f10e1728a12a8a8f21fab6b72d14e1c35e7d2d44e2d1a1be4
-- 
cgit v0.12



http://pkgs.fedoraproject.org/cgit/perl-Net-LDAP-Server-Test.git/commit/?h=master=39fcfbaca3684053e74fe1d3203c0307dd2f0633
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

corsepiu uploaded Net-LDAP-Server-Test-0.22.tar.gz for perl-Net-LDAP-Server-Test

[notifications]

d311b83a9941c881eb3e1737a5afac3e29bca536a2c1727d2c08261ce4974ef99e2f7130acc1736f10e1728a12a8a8f21fab6b72d14e1c35e7d2d44e2d1a1be4
  Net-LDAP-Server-Test-0.22.tar.gz

http://pkgs.fedoraproject.org/lookaside/pkgs/perl-Net-LDAP-Server-Test/Net-LDAP-Server-Test-0.22.tar.gz/sha512/d311b83a9941c881eb3e1737a5afac3e29bca536a2c1727d2c08261ce4974ef99e2f7130acc1736f10e1728a12a8a8f21fab6b72d14e1c35e7d2d44e2d1a1be4/Net-LDAP-Server-Test-0.22.tar.gz
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Stephen Gallagher]

On 12/13/2016 09:36 AM, Dave Love wrote:
> Simo Sorce  writes:
> 
>> If you really need to automate it because typing a password is too hard:
>> cat ~/.mykrbpassword | kinit myusername
> 
> It needs to be automated principally because the password is not
> memorable.  I assume infrastructure people would rather we don't use the
> least secure credentials we can.
> 
> There is actually a Kerberos mechanism for storing credentials even if
> it somewhat defeats the object, particularly on a shared system.  It
> would be better if you could forward the GSS identities over ssh, but I
> don't see that you can.

Of course you can: `ssh -K`. From the manpage:

 -K  Enables GSSAPI-based authentication and forwarding (delegation) of
GSSAPI credentials to the server.





signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

limb changed corsepiu's 'commit' permission on perl-Net-LDAP-Server-Test (f25) to 'Approved'

[notifications]

limb changed corsepiu's 'commit' permission on perl-Net-LDAP-Server-Test (f25) 
to 'Approved'
https://admin.fedoraproject.org/pkgdb/package/perl-Net-LDAP-Server-Test/
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Dave Love]

Simo Sorce  writes:

> If you really need to automate it because typing a password is too hard:
> cat ~/.mykrbpassword | kinit myusername

It needs to be automated principally because the password is not
memorable.  I assume infrastructure people would rather we don't use the
least secure credentials we can.

There is actually a Kerberos mechanism for storing credentials even if
it somewhat defeats the object, particularly on a shared system.  It
would be better if you could forward the GSS identities over ssh, but I
don't see that you can.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Packagers - Flag day 2016 Important changes

[Dave Love]

Simo Sorce  writes:

> On Tue, 2016-12-13 at 10:54 +, Dave Love wrote:
>> Kevin Fenzi  writes:
>> 
>> > This is included in the fedora-packager-0.6.0 update. 
>> >
>> > Make sure your /etc/krb5.conf has the include to include them
>> > from /etc/krb5.conf.d/ though
>> 
>> That will break Heimdal, for people who use that.
>
> Heimdal is not packaged in Fedora,

It clearly is, and I have the package installed.

> if you care for compiling and using
> it yourself I am sure you can change the default ccache scheme as well.
>
> Simo.

Oh, please.  The above was nothing to do with ccache anyhow.  (I don't
know how it works currently, but Samba4 used to be based on Heimdal, and
I thought inherited that sort of thing.  When I last worked on it,
krb5.conf was meant to be interchangeable.)

I did actually ask about Heimdal initially.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org