EPEL epel beta report: 20140429 changes
Compose started at Tue Apr 29 08:15:03 UTC 2014 New package: createrepo_c-0.3.0-1.el7 Creates a common metadata repository New package: erlang-meck-0.7.2-5.el7 A mocking library for Erlang New package: galera-25.3.5-5.el7 Synchronous multi-master wsrep provider (replication engine) New package: geany-1.24.1-1.el7 A fast and lightweight IDE using GTK2 New package: golang-github-kdar-factorlog-0-0.1.git814d8f7.el7 Fast logging infrastructure for Go New package: lib3ds-1.3.0-16.el7 3D Studio file format library New package: mariadb-galera-5.5.36-10.el7 A community developed branch of MySQL New package: munin-2.0.21-1.el7.1 Network-wide graphing framework (grapher/gatherer) New package: perl-GraphViz-2.14-4.el7 Interface to the GraphViz graphing tool New package: php-horde-content-2.0.3-2.el7 Tagging application New package: php-horde-imp-6.1.7-2.el7 A web based webmail system New package: python-bitarray-0.3.5-8.el7 Efficient Array of Booleans --C Extensions New package: thunderbird-24.5.0-1.el7 Mozilla Thunderbird mail/newsgroup client Updated Packages: htop-1.0.3-1.el7 * Mon Apr 28 2014 Morten Stevens mstev...@imt-systems.com - 1.0.3-1 - Update to 1.0.3 - Should resolve BZ#925557, BZ#987805, BZ#1091943 * Sat Aug 03 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.0.2-3 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild php-PHP-CSS-Parser-5.1.2-1.el7 -- * Mon Apr 28 2014 Remi Collet r...@fedoraproject.org - 5.1.2-1 - update to 5.1.2 php-horde-horde-5.1.6-3.el7 --- * Tue Apr 29 2014 Remi Collet r...@fedoraproject.org - 5.1.6-3 - obsoletes horde only in f21 and epel7 php-symfony-icu-1.2.1-1.el7 --- * Mon Apr 28 2014 Shawn Iwinski shawn.iwin...@gmail.com - 1.2.1-1 - Updated to 1.2.1 (BZ #1078756) * Wed Nov 27 2013 Shawn Iwinski shawn.iwin...@gmail.com - 1.2.0-1 - Updated to 1.2.0 * Wed Nov 27 2013 Shawn Iwinski shawn.iwin...@gmail.com - 1.1.0-3 - Added conflicts - Minor comments and description updates php-tcpdf-6.0.072-1.el7 --- * Mon Apr 28 2014 Remi Collet r...@fedoraproject.org - 6.0.072-1 - update to 6.0.072 puppet-3.5.1-1.el7 -- * Mon Apr 28 2014 Sam Kottler skott...@fedoraproject.org.org 3.5.1-1 - Update to 3.5.1 * Tue Apr 08 2014 Lukas Zapletal lzap+...@redhat.com 3.4.3-3 - RHBZ#1070395 - fixed error in postun scriplet - Reformatted all scriplets and corrected exit codes * Tue Apr 08 2014 Lukas Zapletal lzap+...@redhat.com 3.4.3-2 - Fixed systemd unit files - wrappers are now in use and master starts with correct context * Mon Feb 24 2014 Sam Kottler skott...@fedoraproject.org - 3.4.3-1 - Update to 3.4.3 Summary: Added Packages: 13 Removed Packages: 0 Modified Packages: 6 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL RFC: Strategy for python3 versions
Hi guys, Orion has submitted a python34 package for EPEL and I'm going to review them soon if no one beats me to it. In parallel with getting that approved I'd like to ask about the general strategy we'd like to take with maintaining python3 in EPEL. Python3 is an evolving language. New 3.N releases bring new features, bugfixes, and both backwards compatibility breaking and backwards compatibility enhancing changes (For instance, 3.3 brought the ability to mark regular text strings with the u prefix to match with python2.x. 3.5 will bring back formatting methods for byte strings.) Currently, there are a good many python libraries that work with both python2 and python3 but few libraries and few applications that are python3-only. Upstream, python3 releases generally see 18 months of bugfix updates and 5 years of security fixes[1]_. As Orion has pointed out, it would be hard for us to maintain a python3 release past upstream's EOL date as there's a lot of code in a python3 package (Not to mention the stack of packages that we'll build on top of it.) In addition, I am a little worried about the amount of time we may end up having to devote to keeping multiple python3.N packages (and stacks of packages for them) alive if we only retire old python3 releases when upstream ceases to provide support for them (back of the envelope calculations are that if we don't skip any python3.N releases, we'd be attempting to maintain 4-5 python3 releases before the first of those EOL's upstream). I'd like to propose that we attempt to maintain 2 python3 releases at any one time. We'll create python3.4 now. When python3.5 comes out in 18 months (less since python3.4 has been out for several months), we'll package that in addition. When python3.6 comes out (3 years), we'll package that and retire python3.4. Pluses: * This gives users some time to verify that their homegrown applications continue to work with the newer python3 package that we produce before the old one goes EOL. * This means that we're only working on 3 versions of python3 at a time (the two we expect users to use and the next version that we're tracking as upstream works on finishing it). * This gives us a chance to update frameworks, libraries, and other stacks of software built on top of python3 at the same time as we create the new interpreter package. So you could get python3.4 with Django-1.6.x and you could get python3.5 with Django-1.8.x Negatives: * Users will have to reverify and port apps written against python3 to the new interpreter version sometime in the 3 year lifespan of the python3 package they originally wrote it against. * Package maintainers who are creating packages that run on python3 will need to submit new packages for python3.4, python3.5, etc. * Users may have to port to both new versions of python3 and to new versions of some libraries they depend on (because we took the opportunity to update those libraries for the new python3 interpreter stack). Precedents: * With mediawiki, we now ship versioned packages and retire the old versions when upstream stops shipping updates. The stacks of packages built on top of mediawiki have to be produced for each mediawiki version. Alternatives: * Never retire the python3 packages. This leaves us trying to support the release once upstream stops support. Since new python3 releases are in demand, we'd probably end up trying to maintain all of the python3 releases that came out between when RHEL-N was released and when RHEL-N+1 releases (because maintainer focus usually shifts to building packages for RHEL-N+1 then). * Retire the python3 packages when upstream stops support. This defers the pain for users (They can use a python3.N version for about 5 years instead of about 3 years). However, it means that we're maintaining 4-5 versions of python3 at a time instead of 2-3 What do people think? Is this something we can do within the policies of EPEL? Does it make sense to go forward with this? Is it better to go with one of the alternatives? .. [1]_: Previous versions of python3 have a lifespan defined in their PEP. For instance, this one for python3.3: http://legacy.python.org/dev/peps/pep-0398/#lifespan The lifespan for the previous versions are the same: * bugfix updates for python3.N approximately every 4-6 months for approximately 18 months. * After the release of python3.N+1, a final bugfix of python3.N is released. * After that, security updates (source only) will be released until 5 years after the initial release of 3.N. 3.4 doesn't have this lifespan section but that's probably an oversight (I can ask Larry Hastings to clarify that if need be). -Toshio pgpD0KdHyh6Gn.pgp Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RFC: Strategy for python3 versions
On Tue, 29 Apr 2014 16:54:31 -0700 Toshio Kuratomi a.bad...@gmail.com wrote: ...snip... What do people think? Is this something we can do within the policies of EPEL? Does it make sense to go forward with this? Is it better to go with one of the alternatives? ...snip... I like the plan. I'm happy to help co-maintain/package monkey versions. kevin signature.asc Description: PGP signature ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL thoughts or views on packages deliberately left out of rhel?
The RC for el7 specifically omits packages that have drawn interest in the past. A few examples of such packages would be kmail and pidgin. kmail is ordinarily part of the kde-pim suite, but is stripped from the final build via some 'rm' handiwork in the spec. Pidgin is omitted from the build via a check to see if the build host is rhel. The libs are used and included, but the binary is no longer produced. I'm curious to know if anyone from the epel side has thought about how these might be included. This doesn't appear to be a more straightforward case like thunderbird, but would require some prep-work to not overwrite core packages. Thoughts as to how this might be accomplished? -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL RFC: Strategy for python3 versions
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/29/2014 05:54 PM, Toshio Kuratomi wrote:
Hi guys,
Orion has submitted a python34 package for EPEL and I'm going to
review them soon if no one beats me to it. In parallel with
getting that approved I'd like to ask about the general strategy
we'd like to take with maintaining python3 in EPEL.
Python3 is an evolving language. New 3.N releases bring new
features, bugfixes, and both backwards compatibility breaking and
backwards compatibility enhancing changes (For instance, 3.3
brought the ability to mark regular text strings with the u
prefix to match with python2.x. 3.5 will bring back formatting
methods for byte strings.)
...
I'd like to propose that we attempt to maintain 2 python3 releases
at any one time. We'll create python3.4 now. When python3.5 comes
out in 18 months (less since python3.4 has been out for several
months), we'll package that in addition. When python3.6 comes out
(3 years), we'll package that and retire python3.4.
Pluses: * This gives users some time to verify that their homegrown
applications continue to work with the newer python3 package that
we produce before the old one goes EOL. * This means that we're
only working on 3 versions of python3 at a time (the two we expect
users to use and the next version that we're tracking as upstream
works on finishing it). * This gives us a chance to update
frameworks, libraries, and other stacks of software built on top of
python3 at the same time as we create the new interpreter package.
So you could get python3.4 with Django-1.6.x and you could get
python3.5 with Django-1.8.x
Negatives: * Users will have to reverify and port apps written
against python3 to the new interpreter version sometime in the 3
year lifespan of the python3 package they originally wrote it
against. * Package maintainers who are creating packages that run
on python3 will need to submit new packages for python3.4,
python3.5, etc. * Users may have to port to both new versions of
python3 and to new versions of some libraries they depend on
(because we took the opportunity to update those libraries for the
new python3 interpreter stack).
So, I want to be explicit as to how we handle python3 modules in EPEL.
Originally I was hoping we could simply have python3.4 provide
python3 and maintainers could branch their current Fedora python
modules for epel7 and build as is resulting in python3-module packages
as in Fedora.
However, I don't see how we transition easily to the next python3
release. I suppose we could do a side tag and rebuild everything then
have a flag day release. Does this seem workable (I don't think so)?
If we're going to require having python34-module packages are we going
to require new reviews, or can we simply have people name them with
%package -n python34-module in the epel7 branch? Would we have people
maintain multiple versions at a time in a package? This seems like
the workable version. I'm afraid that requiring new review all the
time will be a serious impediment.
We'll have %{__python34} etc macros then too.
Alternatives: * Never retire the python3 packages. This leaves us
trying to support the release once upstream stops support. Since
new python3 releases are in demand, we'd probably end up trying to
maintain all of the python3 releases that came out between when
RHEL-N was released and when RHEL-N+1 releases (because maintainer
focus usually shifts to building packages for RHEL-N+1 then). *
Retire the python3 packages when upstream stops support. This
defers the pain for users (They can use a python3.N version for
about 5 years instead of about 3 years). However, it means that
we're maintaining 4-5 versions of python3 at a time instead of 2-3
What do people think? Is this something we can do within the
policies of EPEL? Does it make sense to go forward with this? Is
it better to go with one of the alternatives?
I like the plan of supporting 2 versions at a time. I'm willing to
defer deciding on what the next version should be till later. Perhaps
3.5 won't be all that compelling and we'll want to wait for 3.6.
Finally:
python34-3.4
or python3.4-3.4
or python-3.4-3.4
or python3-3.4-3.4?
Keep provides python(abi) = 3.4?
- --
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlNgUFwACgkQORnzrtFC2/ujzQCguem5bziFQQZzn1WfLPZaPbuy
adMAoMOmF2Al81HWqxCFGYJgBr5UZcjZ
=OMyV
-END PGP SIGNATURE-
___
epel-devel mailing list
epel-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: EPEL thoughts or views on packages deliberately left out of rhel?
On 2014-04-30 06:57, Jim Perrin wrote: The RC for el7 specifically omits packages that have drawn interest in the past. A few examples of such packages would be kmail and pidgin. kmail is ordinarily part of the kde-pim suite, but is stripped from the final build via some 'rm' handiwork in the spec. Pidgin is omitted from the build via a check to see if the build host is rhel. The libs are used and included, but the binary is no longer produced. In the pidgin case is libpurple the main thing that gets used in RHEL? If so but it's under the 'pidgin' namespace then maybe a -bin package could be provided via EPEL or some other means. Alternatively it might make sense to file a BZ to have it moved under a different package name altogether? kmail seems like a more simple case - build an alternate spec which removed everything from the source tarball *except* kmail? Just spitballing here to get the conversation started... -s I'm curious to know if anyone from the epel side has thought about how these might be included. This doesn't appear to be a more straightforward case like thunderbird, but would require some prep-work to not overwrite core packages. Thoughts as to how this might be accomplished? ___ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Self Introduction: Tetsumune KISO
Hi all, My name is Tetsumune KISO. I have been a network engineer at telecom carrier. Recently I have submitted a review request: https://bugzilla.redhat.com/show_bug.cgi?id=1089110 This is my first package and I need a sponsor. I'm very happy if you accept this package. Best Regards, Tetsumune KISO -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Headsup: Rebased Xorg coming to a rawhide near you
Hi All, During the last few days I've been preparing a rebase of Xorg to 1.15.99.902 all packages have been build into the f21-xorg tag now, and I've just request rel-eng to move them to rawhide proper. So the next rawhide compose, or maybe the one after that will have an all new Xorg stack. I've tested this on a variety of machines and I don't expect any issues, but you never know. This rebase also adds the capability for the Xserver to run without root rights. I'll write a blog post about that, including some testing instructions, once it has landed. Note that the xserver will still run as root by default for now, because most display managers or not ready for running the xserver as a user yet (since the xserver now can no longer do this itself they will need to setup a session and controlling vt for it). Regards, Hans -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction : Florian Tani
Hi everybody, I'm writing today because I have submitted my first package for review : https://bugzilla.redhat.com/show_bug.cgi?id=1092431https://bugzilla.redhat.com/show_bug.cgi?id=1090933 Hello, my name is Florian Tani. I am Computer Engineering student , second year at Metropolitan Univeristy of Tirana . Graduated for Physics Engineering with Bachelor degree from Polytechnic University of Tirana. Professionally, I'm a Technical Support/IT in a company in Tirana,Albania.My work involves Technical Support as operator for Internet/Telephone Services technicians in-field-work and daily routine as System/Network Administratior . In spare i have been involved in projects related with Arduino , Raspberry Pi. I am interested create RPM-s and maintain sysadmin / scientific tools. I will need a sponsor and i hope someone will come out upon my request. Best Regards, Florian Tani -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Mon, 28.04.14 15:11, Toshio Kuratomi (a.bad...@gmail.com) wrote: On Apr 28, 2014 5:01 PM, Daniel J Walsh dwa...@redhat.com wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Would removing the requires on systemd and doing: /usr/bin/systemctl reload ||: Work for these cases? Note that all the invocations of systemctl done by the systemd rpm macros are suffixed with /dev/null 21 || :, as it is customary for rpm scriplets. Hence there's little to do really, except dropping the deps, and leaving everything else in place... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images? Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: an that is why we need a firewall - Re: When a yum update sets up an MTA ...
On 04/28/2014 08:09 PM, Florian Weimer wrote: On 04/28/2014 12:42 PM, David Woodhouse wrote: Actually, I think the best way to fix this is with SELinux, rather than iptables. Why go for an overly complex solution where authorised processes have to prod a firewall dæmon to change the iptables configuration, when the kernel has a perfectly good firewall built in as a fundamental part of the IP stack? Send a TCP SYN to a port which nobody's listening on, and you'll get a TCP RST back. Send a UDP packet to closed port, and you'll get an ICMP 'port unreachable' back. No need for iptables at all. All you need to do, if you really want to control incoming connections, is use SELinux to limit who can bind() and listen() to certain ports. Can we make this stick for the unconfined_t user as well? How can system administrators configure exceptions? What about developers who need to bind to various ports, e.g. while running test suites? Will it be as straightforward as with firewalld? An explicit failure on bind() might actually give us better error reporting (especially if the EPERM details idea is implemented). I like the SELinux idea. To be able to bind only in a trusted environment has advantages, but also disadvantages: + You have the possibility of error reporting if the app is designed in the way to fail gracefully in the unable to open port case. - Only works in a simple network environment that needs to be at best static. - Does not work with more than one active connection where some are trusted and others are not without adding mechanisms in all network services and apps that will take care about this internally with configuration and policies. - Is not working while switching the network environment from trusted to untrusted or vice versa without having network services and apps that will react gracefully on a now closed port or that are able to bind later on to. Rebooting the system, restarting all network services and apps or logging out and back in is not a good solution for this. Ergo: You need to have very smart network services and apps with this. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
On 04/28/2014 03:49 PM, Adam Jackson wrote: On Mon, 2014-04-28 at 09:58 -0400, Casey Dahlin wrote: On Mon, Apr 28, 2014 at 08:57:27AM -0400, Adam Jackson wrote: On Sun, 2014-04-27 at 23:02 +0100, Andrew Price wrote: On 24/04/14 15:13, Lennart Poettering wrote: We probably should make setjmp()-freeness a requirement for all code included in Fedora. Would it be worth the effort, and how feasible is it anyway? I don't think it'd be worth the effort, and I think the burden of computing feasibility should rest with those who think it _is_ worth the effort. Well, we could consider banning it from new packages and just let attrition take care of the rest. We could. I still wouldn't consider that a productive use of time. It's a rare API that can't be misused, I'd much prefer if we approached code quality by _actually reading the code_ rather than deciding with grep what we will and won't accept. I know that's a radical idea, that as packagers we ought actually to know the language of the code being packaged, but I think it has merit. Indeed. setjmp has its uses; they're not very common, but it's not unreasonable for an upstream programmer to use setjmp. Andrew. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: Application Installer Continued
= Proposed System Wide Change: Application Installer Continued = https://fedoraproject.org/wiki/Changes/AppInstallerContinued Change owner(s): Richard Hughes for the implementation, Ryan Lerch and Allan Day for the design rhug...@redhat.com Fully integrate the new application installer with Fedora, and complete its feature set. == Detailed Description == gnome-software will support installing system add-ons such as fonts and codecs. It will show additional metadata for applications: screenshots, ratings, other details. We will also work with the Fedora infrastructure team to obtain the metadata online for all applications instead of shipping it statically for a limited set. The metadata for application needs to be expanded and its quality monitored. Screenshots need to be taken or updated. The update monitoring and downloading functionality will be moved from the gnome-settings-daemon updates plugin into gnome-software. To implement this, gnome-software will be turned into a session service, and the updates plugin will be removed from gnome-settings-daemon. A gnome-shell search provider will offer installable applications as search results. gnome-software will allow to customize the app folders that are displayed in the gnome-shell app picker. We will switch to using the hawkey PackageKit backend. We also want to try to integrate Fedora accounts for collecting ratings and installed package lists, but this requires coordination with the Fedora infrastructure team. The priorities for gnome-software 3.12 are also tracked upstream [1]. == Scope == * Proposal owners: ** Add add-on support (DONE) ** Display additional metadata in details page (DONE) ** Implement a GNOME shell search provider (DONE) ** Turn gnome-software into a session service and take over updates plugin functionality (DONE) ** Implement app folder configuration (DONE) ** Turn search into search-as-you-type ** Implement Fedora account integration ** Replace old gnome-packagekit package installation dialogs (DONE) ** Switch PackageKit to use the hawkey backend (DONE) * Infrastructure: ** Extract metadata and icons when building packages in koji [2] ** Make metadata available for packaged applications in Fedora ** Make application icons available ** Make application screenshots available ** Make it possible to create Fedora accounts from the client-side ** Allow storing small amount of per-user data for users with a Fedora account * Application packagers ** Add application metadata to their packages, ideally sending it upstream * Marketing, documentation ** Assist with review and quality control of application metadata ** Assist with selecting featured applications * Policies and guidelines: ** We want to use the hawkey backend in PackageKit while the default commandline utility is still yum; this kind of separation was rejected by Fesco in the past for zif, will need to ask again (DONE, approved conditionally) ** The packaging guidelines for applications should be updated to require application metadata in addition to a desktop file ** The update experience will also benefit from proposed changes to batch updates, but batched updates are not a strict requirement for the new app installer [1] https://wiki.gnome.org/Apps/Software#Priorities_.26_Plans [2] https://fedorahosted.org/rel-eng/ticket/5721 rel-eng ticket ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: Wayland
= Proposed System Wide Change: Wayland = https://fedoraproject.org/wiki/Changes/Wayland Change owner(s): Matthias Clasen and the desktop team mcla...@redhat.com, desk...@lists.fedoraproject.org Port the GNOME desktop to Wayland. == Detailed Description == GNOME is being ported to Wayland. In particular GNOME shell is changed to run as a Wayland compositor instead of an X11 compositor. Other components of GNOME that currently talk directly to the X server, such as gnome-settings- daemon or gnome-control-center, will be ported to corresponding Wayland interfaces. Many GTK+ applications will just work, using the existing Wayland backend. Applications that make use of X-specific APIs will be supported with the xwayland X server, which is started on demand. gdm will be changed to support both Wayland-based sessions and X-based sessions. This change is targeted at F21. For F20, we aim for having an experimental GNOME shell Wayland compositor available, without necessarily having all the surrounding desktop infrastructure ported. To avoid destabilizing the X compositor, mutter will ship two separate libraries, and gnome-shell will ship two binaries that will link against them. Concretely, we plan to have a separate mutter-wayland package. For more details, see this page [1]. == Scope == * Proposal owners: ** Port GNOME shell to be a Wayland compositor ** Implement Wayland equivalents for X11 APIs such as XRANDR, XI2 and accessibility features ** Port gnome-settings-daemon, gnome-control-center, gnome-desktop from X11 APIs to Wayland equivalents ** Enable gdm to launch Wayland sessions ** Complete the GTK+ Wayland backend to be on par with the X11 backend ** Package mutter-wayland as a separate package review [2] (DONE) * Other developers: ** The X team needs to improve xwayland to be good enough for all X11 application - in practice this means we need X 1.16 ** The X team needs to cooperate with us in reimplementing some X11 APIs ** The X team needs to package libevdev (DONE) ** The X team needs to package libinput (DONE) ** It is not necessary for all spins or all desktop environments in Fedora to switch to Wayland at the same time (or ever) * Release engineering: ** No tasks anticipated * Policies and guidelines: ** Once we have a basic Wayland-based GNOME session, it would be good to encourage testers and packagers to test their applications under Wayland ** For applications that are known not to work under Wayland, we will need guidelines for how to ensure that they will transparently run under xwayland [1] https://wiki.gnome.org/ThreePointNine/Features/WaylandSupport [2] https://bugzilla.redhat.com/show_bug.cgi?id=1007445 ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 System Wide Change: Default Local DNS Resolver
= Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Change owner(s): P J P p...@fedoraproject.org, Pavel Šimerda pav...@pavlix.net, Tomas Hozza tho...@redhat.com To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately, as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally. This change was submitted after the Submission deadline. == Detailed Description == There are growing instances of discussions and debates about the need for a trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are multiple reasons for having such a resolver, importantly security usability. Security protection of user's privacy becomes paramount with the backdrop of the increasingly snooping governments and service providers world wide. People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust. Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. (See: [1], [2], [3]) Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, having a trusted local DNS resolver will not only be imperative but be unavoidable. Because it will perform the most important operation of establishing trust between two parties. All DNS literature strongly recommends it. And amongst all discussions and debates about issues involved in establishing such trust, it is unanimously agreed upon and accepted that having a trusted local DNS resolver is the best solution possible. It'll simplify and facilitate lot of other design decisions and application development in future. (See: [1], [2], [3]) People:- * Petr Spacek * Paul Wouters * Simo Sorce * Dmitri Pal * Carlos O'Donell == Scope == * Proposal owners: Proposal owners shall have to ** define the syntax and semantics for new configuration parameters/files. ** persuade and coordinate with the other package owners to incorporate new changes/workflow in their applications. * Other developers: (especially NetworkManager and the likes) ** would have to implement the new features/workflow for their applications adhering to the new configurations and assuming the availability of the '''trusted''' local DNS resolver. ** NetworkManager already has features capability to support local DNS resolvers. Though few details are still under development, but are expected to realize in near future. Please see [4] * Release engineering: ** would have to ensure that trusted local DNS resolver is available throughout the installation stage and the same is installed on all installations including LiveCDs etc. * Policies and guidelines: ** the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.) would have to ensure that their DNS resolver starts at boot time and works out of the box without any user intervention. ** NetworkManager and others would have to be told to not tamper with the local nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver entries in a separate configuration file. [1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html [2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html [3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html [4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 Self Contained Change: Docker Cloud Image
= Proposed Self Contained Change: Docker Cloud Image = https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image Change owner(s): Cloud SIG / Sandro Mathys r...@fedoraproject.org New Fedora product: Fedora Docker Cloud Image - Docker host ready to go. == Detailed Description == Fedora Cloud agreed to make a base image plus several tailored to specific purposes. This is one of the tailored ones — Docker host ready to go. While basically that simply means only just adding docker-io to the base image, this is (also) intended to be our response to CoreOS. Therefore, depending on further discussion and user input, we might also add etcd [1] and fleet [2] to the mix. Furthermore, the Cloud SIG considers this their most radical image, riding the very front of the leading edge. (Yeehaw!) Several approaches (read: bonus objectives) are under consideration but not crucial to the product itself: * Fedora Atomic Initiative [3] (aka rpm-ostree) to allow for atomic updates. We might further choose to remove yum/dnf from the image in favor of ostree. * Replace cloud-init with min-metadata-service, CoreOS' cloud-init or other alternatives. We'd like to find a leaner solution (read: less Requires) and one that is better (or easier) tailored to Fedora. * Remove Python from this image to reduce the footprint. Note, that this can only be achieved if yum/dnf AND cloud-init are replaced by other solutions as explained in the above points. It should be noted that most of these tools are currently under heavy construction but might be ready in time. If they are, it's still up to discussion whether they will be included. If they aren't, we might punt them to F22 or later. Either way, they won't impact the completion of this change's main goals and are only listed for completeness' sake. == Scope == * Proposal owners: Regarding the core objective, it's just about creating a new kickstart file (probably even %include-ing the base one) add some minor stuff and make sure it gets built into a new image. Also, for added security, we'd like to see Docker and SELinux integrate better. There's already work going on about this. ** The bonus objectives (i.e. leading edge approaches) further require: *** ostree to work with SELinux *** Creating a filesystem tree for ostree that equals the filesystem of the image as created by traditional means *** min-metadata-service to gain the ability to execute scripts just like cloud-init does *** CoreOS' cloud-init or other alternatives to be packages (and possibly tailored) for Fedora * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) [1] https://github.com/coreos/etcd [2] https://github.com/coreos/fleet [3] http://rpm-ostree.cloud.fedoraproject.org/ ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F21 Self Contained Change: LVM Cache Logical Volumes
= Proposed Self Contained Change: LVM Cache Logical Volumes = https://fedoraproject.org/wiki/Changes/Cache_Logical_Volumes Change owner(s): Alasdair G. Kergon a...@redhat.com, David Cantrell dcant...@redhat.com, Dave Lehman dleh...@fedoraproject.org LVM can now use fast block devices (e.g. SSDs and PCIe Flash) to improve the performance of larger but slower block devices. These hierarchical or layered logical volumes are called Cache Logical Volumes in LVM. == Detailed Description == LVM is now capable of using fast block devices (e.g. SSDs) as write-back or write-though caches for larger slower block devices. Users can create cache logical volumes to improve the performance of their existing logical volumes or create new cache logical volumes composed of a small and fast device coupled with a large and slow device. These cache logical volumes can be used with most LVM segment types, including RAID 1/4/5/6/10, linear, stripe and thin pools. == Scope == * Proposal owners: The LVM team must deliver the lvm2 package implementing cache LV (already included in release 2.02.106) * Other developers: N/A (not a System Wide Change) The Anaconda team must develop a UI for configuring cache LVs during installation. If Anaconda support is not provided, users will have to configure cache LVs after installation or by dropping into a command line. Also, Anaconda could fail if installing a new OS onto an existing cache LV if support is not provided. Anaconda team signed as co-owners of this Change. The dracut team must provide boot support. If dracut does not provide support, cache LVs will not be usable as root devices. * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-WWW-OrangeHRM-Client/f19] 0.7.2 bump
commit 379d5b68f385e8845f3aa108485c3a655e00b5da
Author: Petr Písař ppi...@redhat.com
Date: Tue Apr 29 14:47:28 2014 +0200
0.7.2 bump
.gitignore |1 +
perl-WWW-OrangeHRM-Client.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6029570..bb53321 100644
--- a/.gitignore
+++ b/.gitignore
@@ -6,3 +6,4 @@
/WWW-OrangeHRM-Client-v0.6.0.tar.gz
/WWW-OrangeHRM-Client-v0.7.0.tar.gz
/WWW-OrangeHRM-Client-v0.7.1.tar.gz
+/WWW-OrangeHRM-Client-v0.7.2.tar.gz
diff --git a/perl-WWW-OrangeHRM-Client.spec b/perl-WWW-OrangeHRM-Client.spec
index 6c06163..3b88ed5 100644
--- a/perl-WWW-OrangeHRM-Client.spec
+++ b/perl-WWW-OrangeHRM-Client.spec
@@ -1,6 +1,6 @@
%global tarname WWW-OrangeHRM-Client
Name: perl-%{tarname}
-Version:0.7.1
+Version:0.7.2
Release:1%{?dist}
Summary:Client for OrangeHRM
License:GPL+
@@ -53,6 +53,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Apr 29 2014 Petr Pisar ppi...@redhat.com - 0.7.2-1
+- 0.7.2 bump
+
* Tue Dec 17 2013 Petr Pisar ppi...@redhat.com - 0.7.1-1
- 0.7.1 bump
diff --git a/sources b/sources
index 9ff1f5e..a15ad80 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-8522ef9ebf67dfcb1fa3104e0649c35d WWW-OrangeHRM-Client-v0.7.1.tar.gz
+a9c86b61663dabe6df4b06513216964d WWW-OrangeHRM-Client-v0.7.2.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F21 System Wide Change: Application Installer Continued
2014-04-29 13:57 GMT+02:00 Jaroslav Reznik jrez...@redhat.com: = Proposed System Wide Change: Application Installer Continued = https://fedoraproject.org/wiki/Changes/AppInstallerContinued == Release Notes == The application installer, gnome-software is now more fully integrated and provides more functionality. This means very little and after reading this my I can't help asking why would anybody want me to read this sentence? Either describe what's new, or link to such an description, or consider dropping the release note entirely if you don't think users need to know anything specific. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minutes from Env-and-Stacks WG meeting (2014-04-29)
#fedora-meeting: Env and Stacks (2014-04-29) Meeting started by mmaslano at 12:04:50 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2014-04-29/env-and-stacks.2014-04-29-12.04.log.html . Meeting summary --- * Copr and Playground plugin part of dnf-plugins-core (mmaslano, 12:07:56) * AGREED: The Env and Stacks WG's suggestion to the dnf-plugins-core maintainers is to create a separate dnf-plugin-copr package with the dnf-plugin-playground subpackage. In addition, we suggest to defer moving copr.py out of the dnf-plugin-core upstream git repository until DNF's API stabilizes (+1:5, 0:0, -1:0) (tjanez, 13:34:07) * AGREED: : The Env and Stacks WG's suggestion to the dnf-plugins-core maintainers is to create a separate dnf-plugin-copr package with the dnf-plugin-playground subpackage. In addition, we suggest to defer moving copr.py out of the dnf-plugin-core upstream git repository until DNF's API stabilizes (+1:5, 0:0, -1:0) (tjanez, 13:34:16) * ACTION: : tjanez will notify the dnf-plugins-core maintainers about our today's discussion and suggestion (tjanez, 13:39:42) Meeting ended at 13:45:57 UTC. Action Items * : tjanez will notify the dnf-plugins-core maintainers about our today's discussion and suggestion Action Items, by person --- * tjanez * : tjanez will notify the dnf-plugins-core maintainers about our today's discussion and suggestion * **UNASSIGNED** * (none) People Present (lines said) --- * tjanez (45) * juhp_ (44) * mmaslano (36) * mirek-hm (28) * hhorak (22) * zodbot (5) * pkovar (2) * bkabrda (0) * samkottler (0) * abadger1999 (0) * juhp (0) * drieden (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
Hello, 2014-04-29 14:15 GMT+02:00 Jaroslav Reznik jrez...@redhat.com: = Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver == Upgrade/compatibility impact == So what *exactly* happens on upgrade? Before the upgrade, most resolv.conf files will not point to 127.0.0.1. What will they point to after the upgrade, and if they will point to 127.0.0.1, which package will actually do that, and what will happen with the old contents of the file? For example, is it assumed that ifcfg-* are always authoritative and it's safe to just overwrite resolv.conf? == User Experience == Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the new system? Generally, the page doesn't actually say *which* resolver will be used. Has that been decided? Or is that intentionally undefined? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Docker Cloud Image
Hello, 2014-04-29 14:35 GMT+02:00 Jaroslav Reznik jrez...@redhat.com: = Proposed Self Contained Change: Docker Cloud Image = https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image == Scope == snip * Release engineering: N/A (not a System Wide Change) Is anything needed for the potential os-tree -based updates system? == Upgrade/compatibility impact == Do the cloud-init replacements imply the need to also replace or extend the metadata provider, or are they compatible? Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: LVM Cache Logical Volumes
Hello, 2014-04-29 14:48 GMT+02:00 Jaroslav Reznik jrez...@redhat.com: = Proposed Self Contained Change: LVM Cache Logical Volumes = https://fedoraproject.org/wiki/Changes/Cache_Logical_Volumes * Other developers: N/A (not a System Wide Change) non-empty content ... so this might be a system-wide change after all? Anyway, this is mostly for dracut, and ... The dracut team must provide boot support. If dracut does not provide support, cache LVs will not be usable as root devices. This implies a fairly significant feature impact, while... snip == Contingency Plan == Dracut: There is already a hardcoded dm-cache installation. If the detection is not done in time, it will work as is. ... this seems to say nothing important will happen? In any case, having someone sign up to do the dracut integration seems like a very desirable way to resolve these things. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
Hello, On Tuesday, 29 April 2014 7:22 PM, Miloslav Trmač wrote: So what exactly happens on upgrade? Before the upgrade, most resolv.conf files will not point to 127.0.0.1. What will they point to after the upgrade, and if they will point to 127.0.0.1, which package will actually do that, and what will happen with the old contents of the file? For example, is it assumed that ifcfg-* are always authoritative and it's safe to just overwrite resolv.conf? After upgrade, the default DNS resolver should listen on 127.0.0.1:53. And the entry will be added to '/etc/resolv.conf' by NetworkManager. The old contents of the file should be passed on to the local resolver as transitory name servers. The actual workflow is currently being worked upon. Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the new system? We tell users to never edit the '/etc/resolv.conf' file and ensure that the local resolver is listening at 127.0.0.1:53. Generally, the page doesn't actually say which resolver will be used. Has that been decided? Or is that intentionally undefined? The choice of the default resolver is not yet done. From the discussion so far unbound(https://unbound.net/) appears to be the strong contender. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. Can the proposal owners clarify for me how this is intended to impact the cloud products? There's general resistance to having more services running by default, and the dns resolvers aren't famous for being lightweight. Plus, some of the assumptions (like People use Fedora on portable/mobile devices which are connected to diverse networks as and when required) do not seem to apply, or may apply in different ways. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On 04/29/2014 06:31 AM, Lennart Poettering wrote: On Mon, 28.04.14 15:11, Toshio Kuratomi (a.bad...@gmail.com) wrote: On Apr 28, 2014 5:01 PM, Daniel J Walsh dwa...@redhat.com wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Would removing the requires on systemd and doing: /usr/bin/systemctl reload ||: Work for these cases? Note that all the invocations of systemctl done by the systemd rpm macros are suffixed with /dev/null 21 || :, as it is customary for rpm scriplets. Hence there's little to do really, except dropping the deps, and leaving everything else in place... Lennart That seems ideal. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On 04/28/2014 06:44 PM, Adam Jackson wrote: On Mon, 2014-04-28 at 17:01 -0400, Daniel J Walsh wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. rpm -q --whatrequires systemd| wc -l 151 On rawhide I see 151 packages on my system which require systemd. We have a couple of options we could add a package called fakesystemd which provides a /usr/bin/systemctl that does nothing and does a provides systemd in the specfile. Then if the user wanted to install systemd into a container it would need to obsolete the fakesystemd package. Or we could break out /usr/bin/systemctl into its own package and have it be smart enough to do nothing if systemd did not exist. Or you could just rpm -e systemd once you've done the initial rpm install, since it's just a Requires(post) and not a permanent Requires? - ajax Although it would get sucked back in if a user did another yum install (Update?) that needed systemctl. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On 04/29/2014 06:33 AM, Lennart Poettering wrote: On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images? Lennart Shrinking the the docker image is more then just size. We want to eliminate packages that are not used (Within reason) to eliminate problems like CVE's. If udev/systemd/kmod had a CVE we would need to update all Container images. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tuesday, 29 April 2014 7:56 PM, Matthew Miller wrote: Can the proposal owners clarify for me how this is intended to impact the cloud products? Cloud products is somewhat of a hazy area(at-least for me). It's unclear how things operate there. Any information about how we could/should address it well is required and most welcome. Please see - https://lists.fedoraproject.org/pipermail/devel/2014-April/198620.html Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Deprecate setjmp/longjmp? [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]
2014-04-27 19:02 GMT-03:00 Andrew Price anpr...@redhat.com: On 24/04/14 15:13, Lennart Poettering wrote: We probably should make setjmp()-freeness a requirement for all code included in Fedora. Would it be worth the effort, and how feasible is it anyway? - Do we have any usage statistics? - How often do we see bugs caused by bad uses of setjmp/longjmp? - Is mitigation instead of blanket removal possible? - How likely is it that /all/ setjmp/longjmp uses can be reasonably replaced? - Is there existing upstream momentum to move away from setjmp/longjmp? (I'm not against the idea but I think it deserves further discussion.) I think setjmp and longjmp should be treated as a warning, and replaced with sigsetjmp and siglongjmp, but not a fatal error, if I recall correctly, grub has its own setjmp/longjmp implementation. Probably should be a rpmlint warning, like the one of libraries that call exit. Andy Paulo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote: = Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Change owner(s): P J P p...@fedoraproject.org, Pavel Šimerda pav...@pavlix.net, Tomas Hozza tho...@redhat.com To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work. Not sure how to fix something like that though... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tue, Apr 29, 2014 at 05:15:57PM +0200, Alexander Larsson wrote: On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote: = Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Change owner(s): P J P p...@fedoraproject.org, Pavel Šimerda pav...@pavlix.net, Tomas Hozza tho...@redhat.com To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work. Not sure how to fix something like that though... Is it possible to use a different loopback device like 127.0.0.53 and then have that point outside the container somehow? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, Apr 29, 2014 at 10:58 AM, Alexander Larsson al...@redhat.com wrote: On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote: On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images? Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too. It's a bug one way or another. Lacking the dep on nm would break weak-modules as you suggest, but afaik Fedora doesn't ship anything that actually uses or leverages weak-modules anyway. So either the dep could be added or the script could be dropped. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tue, 2014-04-29 at 17:15 +0200, Alexander Larsson wrote: On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote: = Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Change owner(s): P J P p...@fedoraproject.org, Pavel Šimerda pav...@pavlix.net, Tomas Hozza tho...@redhat.com To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work. Not sure how to fix something like that though... Any way we can redirect the connection to the host ? On the host we cannot listen on 0.0.0.0 so we cannot make unbound available through normal routing on a different interface. However we can perhaps make it listen on a special virtual interface dedicated to let containers talk to other processes on the host maybe ? (could even be other privileged containers). There is a question of what addresses to use though ... Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default local DNS failover solution needed, nscd?
On Fri, Apr 25, 2014 at 03:58:44PM -0700, Andrew Lutomirski wrote: https://sourceware.org/ml/libc-alpha/2012-12/msg00416.html I've never understood why something like nscd is even worth trying to support. There's a simple, well specified protocol that program can use to talk to a DNS resolver. It's called DNS. Why try to shoehorn it into something else when all you're likely to do is come up with a poor imitation of what you get by sending DNS queries over DNS to a local resolver? Well, nscd does a lot more than just DNS. I'm sure it would be possible to improve/rewrite nscd, but at best you'll match the quality of something like unbound. And you'll never be compatible with all the third-party resolver clients out there. Third-party resolver clients are a valid concern (lwres? app-specific resolvers?). It is interesting that historically, /etc/resolv.conf was the configuration for just the stub resolver built into the C library, but now it has become the configuration for third-party resolvers as well. From the man page lwres(3): The lwresd library implements multiple name service APIs. The standard gethostbyname(), gethostbyaddr(), gethostbyname_r(), gethostbyaddr_r(), getaddrinfo(), getipnodebyname(), and getipnodebyaddr() functions are all supported. To allow the lwres library to coexist with system libraries that define functions of the same name, the library defines these functions with names prefixed by lwres_. To define the standard names, applications must include the header file lwres/netdb.h which contains macro definitions mapping the standard function names into lwres_ prefixed ones. Operating system vendors who integrate the lwres library into their base distributions should rename the functions in the library proper so that the renaming macros are not needed. That last sentence is intriguing to me. Does that mean we could replace/override the dumb stub resolver in glibc with lwres/lwresd system-wide to solve the DNS failover problem? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On tis, 2014-04-29 at 11:21 -0400, Josh Boyer wrote: On Tue, Apr 29, 2014 at 10:58 AM, Alexander Larsson al...@redhat.com wrote: On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote: On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images? Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too. It's a bug one way or another. Lacking the dep on nm would break weak-modules as you suggest, but afaik Fedora doesn't ship anything that actually uses or leverages weak-modules anyway. So either the dep could be added or the script could be dropped. Another alternative is to use eu-nm, which is part of elfutils, which is not 20 meg. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, 29.04.14 10:37, Daniel J Walsh (dwa...@redhat.com) wrote: On 04/29/2014 06:33 AM, Lennart Poettering wrote: On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images? Lennart Shrinking the the docker image is more then just size. We want to eliminate packages that are not used (Within reason) to eliminate problems like CVE's. If udev/systemd/kmod had a CVE we would need to update all Container images. Well, if you are this principled maybe. But do note that we dont really ship suid binaries (except one binary with fscaps which is systemd-detect-virt), and hence by leaving systemd in the image without running it should result in no increased attack surface that wasn't there anyway... Dead code in the image, that cannot be use to acquire new caps isn't much of a security threat... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tue, 2014-04-29 at 22:10 +0800, P J P wrote: Hello, On Tuesday, 29 April 2014 7:22 PM, Miloslav Trmač wrote: So what exactly happens on upgrade? Before the upgrade, most resolv.conf files will not point to 127.0.0.1. What will they point to after the upgrade, and if they will point to 127.0.0.1, which package will actually do that, and what will happen with the old contents of the file? For example, is it assumed that ifcfg-* are always authoritative and it's safe to just overwrite resolv.conf? After upgrade, the default DNS resolver should listen on 127.0.0.1:53. And the entry will be added to '/etc/resolv.conf' by NetworkManager. The old contents of the file should be passed on to the local resolver as transitory name servers. The actual workflow is currently being worked upon. If NetworkManager is used, an upgrade would simply involve dropping a config file into /etc/NetworkManager/conf.d that specifies the dns=[plugin] option. Then, either NM rewrites resolv.conf to 127.0.0.1 (if an NM DNS plugin is used), or NM stops touching resolv.conf entirely (dns=none) and something else handles resolv.conf. In both cases, NetworkManager gets the DNS information from the same places it already does, and passes it along to the caching nameserver automatically. If NetworkManager is not being used on the system, then yes, there are some additional questions which the proposal needs to answer. Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the new system? We tell users to never edit the '/etc/resolv.conf' file and ensure that the local resolver is listening at 127.0.0.1:53. If NetworkManager is being used, users already don't touch resolv.conf, they edit /etc/sysconfig/network-scripts/ifcfg-* files and use DNS1/DNS2/DNS3 and SEARCHES to set DNS information. If NetworkManager is not being used, then the proposal needs to address what config file users *do* edit to ensure that the upstream DNS servers are pushed to the caching nameserver. Dan Generally, the page doesn't actually say which resolver will be used. Has that been decided? Or is that intentionally undefined? The choice of the default resolver is not yet done. From the discussion so far unbound(https://unbound.net/) appears to be the strong contender. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
[ Dropping devel-announce ] On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson al...@redhat.com wrote: Not sure how to fix something like that though... I think in both cases (host and container) it would be best if the local resolver offered a local-only API (e.g. unix domain sockets, kdbus). Would require teaching glibc how to speak that API though. Then if it was a Unix domain socket, we could bind mount that in from the host, same way as is the plan for other shared services. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
2014-04-29 17:15 GMT+02:00 Alexander Larsson al...@redhat.com: On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote: = Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work. Good point; would it be fair to treat this as a blocker? (This also assumes that the docker containers will use the same security policy as the host; i.e. that they will be administered by the same entity, no docker hosting businesses.) Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Docker Cloud Image
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 29 Apr 2014 14:35:55 +0200 Jaroslav Reznik jrez...@redhat.com wrote: = Proposed Self Contained Change: Docker Cloud Image = https://fedoraproject.org/wiki/Changes/Docker_Cloud_Image Change owner(s): Cloud SIG / Sandro Mathys r...@fedoraproject.org New Fedora product: Fedora Docker Cloud Image - Docker host ready to go. == Detailed Description == Fedora Cloud agreed to make a base image plus several tailored to specific purposes. This is one of the tailored ones — Docker host ready to go. While basically that simply means only just adding docker-io to the base image, this is (also) intended to be our response to CoreOS. Therefore, depending on further discussion and user input, we might also add etcd [1] and fleet [2] to the mix. Furthermore, the Cloud SIG considers this their most radical image, riding the very front of the leading edge. (Yeehaw!) Several approaches (read: bonus objectives) are under consideration but not crucial to the product itself: * Fedora Atomic Initiative [3] (aka rpm-ostree) to allow for atomic updates. We might further choose to remove yum/dnf from the image in favor of ostree. * Replace cloud-init with min-metadata-service, CoreOS' cloud-init or other alternatives. We'd like to find a leaner solution (read: less Requires) and one that is better (or easier) tailored to Fedora. * Remove Python from this image to reduce the footprint. Note, that this can only be achieved if yum/dnf AND cloud-init are replaced by other solutions as explained in the above points. It should be noted that most of these tools are currently under heavy construction but might be ready in time. If they are, it's still up to discussion whether they will be included. If they aren't, we might punt them to F22 or later. Either way, they won't impact the completion of this change's main goals and are only listed for completeness' sake. == Scope == * Proposal owners: Regarding the core objective, it's just about creating a new kickstart file (probably even %include-ing the base one) add some minor stuff and make sure it gets built into a new image. Also, for added security, we'd like to see Docker and SELinux integrate better. There's already work going on about this. ** The bonus objectives (i.e. leading edge approaches) further require: *** ostree to work with SELinux *** Creating a filesystem tree for ostree that equals the filesystem of the image as created by traditional means *** min-metadata-service to gain the ability to execute scripts just like cloud-init does *** CoreOS' cloud-init or other alternatives to be packages (and possibly tailored) for Fedora * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) Releng will be needed to make the docker images, and upload them where they need to go, so this is not true * Policies and guidelines: N/A (not a System Wide Change) [1] https://github.com/coreos/etcd [2] https://github.com/coreos/fleet [3] http://rpm-ostree.cloud.fedoraproject.org/ ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTX8bXAAoJEH7ltONmPFDRRnEP/jBACfQcJFfszUZyhem7mMBT Hn3LqAOToPr4UeNyjM/G3CRatWEJ7YImMl+caqgZ0DYECKDHVmQECcbfpR2SnHM6 1xqsvkEL4erFtL6x4i9EeNnxfJPiLoUGENtr/f7OQqTiwdTJG5022ztRFbNLLoag 6khAyx+cn9gJs+/aNPX3C6RO7FfJsFduVVRnhBDOTW6SrY0mzHnBflm9v2ZkewL1 gc66XIeKISbJiX46zNoslKOICR3M+SMwd1+1FrBMhMysvlQuxPbnVmQmY6ilyBbH v2uiEo0VDJLTgeBDvsRllf5kdRN3PUIWBmbW9hlvQjN4CFDugy/kplc1kdDWUnrF 1FDYo6Dc32DEwkJMG9nFyYQ8CmvO3Lp8J54tS0hdlFnpPSf1H6LJTdArSd2mRttZ ceEWzjw5XaCUeJZFn25tABVYnxaJ1asy7IBnaGngeu2uSBXNIaToD/b4FEC3eeuz hhr1lSeAg5JDFFq/H18TtCYVLv4S2lWWv/+nP6md588bxIPcJdojIcY/sptR+EYu DKIs7AZtr8Lk6S+AlHAP762ZkvuasekPOD/XFtDPMaK2KcP67ntRantNITTV9DkD vORr0a56CxEx0fk06PftUGv+9P4VfANVm4g3Kgc7+UI1I9aumrxbdiDNMNwSajth bUIYP6FA807evkV0mCz8 =gwXJ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On 29.4.2014 17:27, Colin Walters wrote: [ Dropping devel-announce ] On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson al...@redhat.com wrote: Not sure how to fix something like that though... I think in both cases (host and container) it would be best if the local resolver offered a local-only API (e.g. unix domain sockets, kdbus). Would require teaching glibc how to speak that API though. Then if it was a Unix domain socket, we could bind mount that in from the host, same way as is the plan for other shared services. It can work only for libraries we are able to modify. Don't forget that there is *a lot* of DNS resolvers. IMHO anything except standard DNS protocol over UDP/TCP is no-go. -- Petr^2 Spacek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, 29.04.14 16:58, Alexander Larsson (al...@redhat.com) wrote: On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote: On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images? Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too. I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora. I'd really recommend to just drop it from the Fedora package... But, even if the size is small that is not the full picture. There are a bunch of dependencies like dbus (the daemon), device-mapper, kmod, and iptables that are recursively pulled in by systemd that don't really device-mapper? iptables? That sounds wrong... Any idea how that gets pulled in? the dm libs might get pulled in indirectly via libcryptsetup, but the other dm tools really shouldn't be. And iptables i really don't see how that's pulled in? dbus (the daemon) is probably something we can turn around to not require. I mean, it's needed during runtime if you boot a full OS container or host, but I figure we don#t really have to pull this in like this... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [RFC] plans for initscripts in F22
On Thu, Apr 24, 2014 at 04:38:07PM +0200, Lukáš Nykrýn wrote: Network initscript. This will be probably the most controversial part. In fedora 21 we will have three different tools for networking (initscripts, NetworkManager and systemd-networkd) and all of them will be installed by default. For various design reasons network One thing I'd love to see is for /sbin/ifup and /sbin/ifdown to keep working roughly as a sysadmin might expect them to, regardless of the network config system in use. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Docker Cloud Image
On Tue, Apr 29, 2014 at 04:01:05PM +0200, Miloslav Trmač wrote: * Release engineering: N/A (not a System Wide Change) Is anything needed for the potential os-tree -based updates system? Possibly. It depends on the exact implementation. == Upgrade/compatibility impact == Do the cloud-init replacements imply the need to also replace or extend the metadata provider, or are they compatible? They have to be compatible (although may not implement all of cloud-init's sometimes-obscure functionality). -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: EPEL Python 3.4 for 7
On Mon, Apr 28, 2014 at 01:45:52PM -0400, Aaron Knister wrote: I think it's a little unrealistic to expect the vendor to namespace their packages although it would be nice and probably the right thing to do. If you buy from Red Hat, you should complain to them. That might have more effect than I have had. Could EPEL, as the 3rd-party layered product, namespace theirs? (e.g. epel-python34). It's more consistent with how other packages store version numbers in the name Unfortunately, this wouldn't be very consistent with the packages as a whole. If you have a bug in the python3 package that's in /usr/bin/python3.4, for instance, you're going to go to bugzilla looking to file against the python34 package, not epel-python34. And we'd be doing this for packages that we don't even build against or assume that people have. We also have no control over what packages Red Hat will choose to scl-ize. In the future, they could create mediawiki119 scls or Turbogears2 scls. So we really need Red Hat to stick to convention and not pollute the toplevel package (although as an aside, the smushing together of version numbers without dots drives me a little crazy so part of me likes the dot in python3.4). I also like the dot in the version number in the name. However, although that solves the problem of conflicting package names for a computer, it doesn't solve the problem for humans. (Why do I have both python3.4 and python34 packages installed? I should be able to get rid of one of those.) It's also not a requirement of scls that they do not contain any dots in the scl name. Future Red Hat supplied scls may put a dot into the name and thus we'll still have conflicts. -Toshio pgpcMQ4X13EdP.pgp Description: PGP signature ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: F21 Self Contained Change: Docker Cloud Image
On Tue, Apr 29, 2014 at 10:35:46AM -0500, Dennis Gilmore wrote: * Release engineering: N/A (not a System Wide Change) Releng will be needed to make the docker images, and upload them where they need to go, so this is not true Of course that is absolutely true. We should fix that in the feature page. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
2014-04-29 17:40 GMT+02:00 Lennart Poettering mzerq...@0pointer.de: On Tue, 29.04.14 16:58, Alexander Larsson (al...@redhat.com) wrote: Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too. I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora. That outdated cruft is AFAICS still part of the RHEL-7 ABI design. Assuming the same people will end up maintaining it whether it is in Fedora or RHEL-7, I can't see that work going away, though whether to maintain it upstream in Fedora or as a RHEL-only patch is basically up to the individual maintainers. Mirek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: Docker Cloud Image
On Tue, Apr 29, 2014 at 10:01 AM, Miloslav Trmač m...@volny.cz wrote: Is anything needed for the potential os-tree -based updates system? Definitely! There's a short term and long term plan. Short term: * Run a separate set of server(s) to do treecompose. Would require some basic level of integration with mainline releng to do stuff like GPG signing and mirroring. Long term: * Teach koji how to do treecompose. This should be relatively easy as far as code goes, but implies a deeper level of integration with rel-eng. * Split out the VM testing infrastructure into a separate project, and run that as a standalone service Do the cloud-init replacements imply the need to also replace or extend the metadata provider, or are they compatible? min-metadata-service is just a client implementation of a standard API, no changes to the provider are necessary. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, Apr 29, 2014 at 11:47 AM, Miloslav Trmač m...@volny.cz wrote: 2014-04-29 17:40 GMT+02:00 Lennart Poettering mzerq...@0pointer.de: On Tue, 29.04.14 16:58, Alexander Larsson (al...@redhat.com) wrote: Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too. I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora. That outdated cruft is AFAICS still part of the RHEL-7 ABI design. Assuming the same people will end up maintaining it whether it is in Fedora or RHEL-7, I can't see that work going away, though whether to maintain it upstream in Fedora or as a RHEL-only patch is basically up to the individual maintainers. Fedora does not, and will not, support the kABI mechanism that is present in the RHEL kernel package. It doesn't make sense in Fedora at all. So maintaining weak-modules in Fedora is pretty limited. You can't test what can't be used, as evident by it not even having the proper deps. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tue, 29 Apr 2014, P J P wrote: Similarly, what do we tell users who used to edit /etc/resolv.conf to do in the new system? We tell users to never edit the '/etc/resolv.conf' file and ensure that the local resolver is listening at 127.0.0.1:53. We should leave a comment in resolv.conf that warns the user. Generally, the page doesn't actually say which resolver will be used. Has that been decided? Or is that intentionally undefined? The choice of the default resolver is not yet done. From the discussion so far unbound(https://unbound.net/) appears to be the strong contender. We've been working with the unbound people to get the features in that we needed. It is the only one that is feature-rich enough for us to currently use (for instance with dynamic reconfiguration when using VPNs). Note that FreeBSD also picked unbound recently for the exact same task. Paul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: EPEL Python 3.4 for 7
On Sat, Apr 26, 2014 at 09:13:12PM -0600, Orion Poplawski wrote: On 04/26/2014 06:55 PM, Toshio Kuratomi wrote: On Apr 26, 2014 11:37 AM, Orion Poplawski or...@cora.nwra.com mailto:or...@cora.nwra.com wrote: One interesting change from RHEL7 beta-rc is the dropping of libdb4 which python3 currently BRs, although I cannot see any evidence in http://kojipkgs.fedoraproject.org//packages/python3/3.4.0/2.fc21/data/logs/x86_64/build.log of python3 actually using it (it seems to be using gdbm instead). Python 3 does use libdb although I think it can use libdb5. Python has a standard library that includes both libdb bindings and gdbm bindings. Hmm, I see no evidence that it makes use of both as currently built. It seems that gdbm is preferred and there are no dependencies on libdb*. On further investigation, I see that you are absolutely right. The bsddb module was removed from python3.0 so we can remove the BuildRequires on db for any python3 packages. See the disclaimer at the top of the python2 docs: https://docs.python.org/2/library/bsddb.html and the PEP: http://legacy.python.org/dev/peps/pep-3108/#maintenance-burden -Toshio pgpILUvRXfVH6.pgp Description: PGP signature ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On tis, 2014-04-29 at 17:40 +0200, Lennart Poettering wrote: On Tue, 29.04.14 16:58, Alexander Larsson (al...@redhat.com) wrote: On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote: On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images? Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too. I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora. I'd really recommend to just drop it from the Fedora package... But, even if the size is small that is not the full picture. There are a bunch of dependencies like dbus (the daemon), device-mapper, kmod, and iptables that are recursively pulled in by systemd that don't really device-mapper? iptables? That sounds wrong... Any idea how that gets pulled in? the dm libs might get pulled in indirectly via libcryptsetup, but the other dm tools really shouldn't be. And iptables i really don't see how that's pulled in? systemd = cryptsetup-libs = device-mapper-libs = device-mapper Don't have time to look up the details atm, but iptable was reached via initscripts somehow. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tue, 2014-04-29 at 17:39 +0200, Petr Spacek wrote: On 29.4.2014 17:27, Colin Walters wrote: [ Dropping devel-announce ] On Tue, Apr 29, 2014 at 11:15 AM, Alexander Larsson al...@redhat.com wrote: Not sure how to fix something like that though... I think in both cases (host and container) it would be best if the local resolver offered a local-only API (e.g. unix domain sockets, kdbus). Would require teaching glibc how to speak that API though. Then if it was a Unix domain socket, we could bind mount that in from the host, same way as is the plan for other shared services. It can work only for libraries we are able to modify. Don't forget that there is *a lot* of DNS resolvers. IMHO anything except standard DNS protocol over UDP/TCP is no-go. I have to concur, unix sockets is a dead end, there are tons of libraries that look at resolv.conf and use the server named there, and they only support the standard DNS protocol over IP (TCP and UDP). Are we going to need a way to bind-mount local ports to containers too ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, 29.04.14 18:03, Alexander Larsson (al...@redhat.com) wrote: On tis, 2014-04-29 at 17:40 +0200, Lennart Poettering wrote: On Tue, 29.04.14 16:58, Alexander Larsson (al...@redhat.com) wrote: On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote: On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images? Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too. I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora. I'd really recommend to just drop it from the Fedora package... But, even if the size is small that is not the full picture. There are a bunch of dependencies like dbus (the daemon), device-mapper, kmod, and iptables that are recursively pulled in by systemd that don't really device-mapper? iptables? That sounds wrong... Any idea how that gets pulled in? the dm libs might get pulled in indirectly via libcryptsetup, but the other dm tools really shouldn't be. And iptables i really don't see how that's pulled in? systemd = cryptsetup-libs = device-mapper-libs = device-mapper Don't have time to look up the details atm, but iptable was reached via initscripts somehow. I wonder if we can break the d-m-l → d-m link... If we can't there's probably little reason to have two packages for this... Lennart -- Lennart Poettering, Red Hat -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
local dns server and flushing negative cache
Looks like we will be able to flush the negative cache between networks in the next version of unbound. Paul ps. this is why I love unbound. Request a useful feature, get it :) -- Forwarded message -- Date: Tue, 29 Apr 2014 04:50:05 From: W.C.A. Wijngaards wou...@nlnetlabs.nl To: Paul Wouters p...@nohats.ca Subject: Re: https://bugzilla.redhat.com/show_bug.cgi?id=1089767 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hoi Paul, On 04/22/2014 03:57 AM, Paul Wouters wrote: https://bugzilla.redhat.com/show_bug.cgi?id=1089767 See discussion. It would be good to have a flush_negative I think. Implemented, in commit 3125. Flushes also the bad key entries from the key cache (because they could be because of nxdomains). Met vriendelijke groeten, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTX2e9AAoJEJ9vHC1+BF+NtfMP/372VN4ZxAlBTQvdNlowX5Gx FbbScLETC4LBbKNNf/3PuTsouOu2hkvcvuoofSY6LIELwIqIN1y4RG8/0O7R7pLv R6JWHNJmedSBOfMvtmszx+DVyFfKizeBBEEEIBzJ36hOnkP10UuWA82zyw0lmrVC Wo23n+NrLlNo+Qcf99E+N5jMfq9WX8hVanbO8alNstOD8IvrjkBsVnLlJPDHUeY7 enebLKTlm5UF3z3VEIJ7L8Hi4L+V7plLpdW4zpDCeWeRoaMlRRS7xaoUiEbdK5tc ogbxMDrpIiZAxcaaXa3jDKvo2v5qfiommNd83m2g5ODfSNE9sqL2hmh1/ffoZgK0 Ko7nw9qI1L0s01jluYcpUya5SirMqZbrXsF6ywL+kRbGAPhOv8oXTTrNMxxH84JJ 7dz2twIMKiIrwFrNoWs73qPGG5H5GShaZre/ecLybaFu21BIeVgoo1l4ULcFR4lQ VRK+8ae1Py82aTFBzSgzUZNYakYuDSgcWcikhSTUdW/1SishZr78qGVeWbdlMf9s dvqHCXihGXmqDjaDd0vmAnJaSxP3N36FyuBzkrBTeuMuOuKnLRNPrLwudbYwsba2 oeY2ss/pYWNJXx5QFm1NfEBKeC/BLN+LG0oxn0MZL3yKkG42Rm5hUEhoFVW+1nKD iiJ4un9x35AT2/ByEJA/ =XfEt -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tue, Apr 29, 2014 at 8:18 AM, Chuck Anderson c...@wpi.edu wrote: On Tue, Apr 29, 2014 at 05:15:57PM +0200, Alexander Larsson wrote: On tis, 2014-04-29 at 14:15 +0200, Jaroslav Reznik wrote: = Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Change owner(s): P J P p...@fedoraproject.org, Pavel Šimerda pav...@pavlix.net, Tomas Hozza tho...@redhat.com To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. This is gonna conflict a bit with docker, and other users of network namespaces, like systemd-nspawn. When docker runs, it picks up the current /etc/resolv.conf and puts it in the container, but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work. Not sure how to fix something like that though... Is it possible to use a different loopback device like 127.0.0.53 and then have that point outside the container somehow? I like this solution, although I think it'll require making unbound bind to 127.0.0.53 for the non-container case, too. OTOH, it would be straightforward to write a tiny stub that forwards 127.0.0.1:53 to something outside the container. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 Self Contained Change: LVM Cache Logical Volumes
On Tue, Apr 29, 2014 at 02:48:51PM +0200, Jaroslav Reznik wrote: = Proposed Self Contained Change: LVM Cache Logical Volumes = https://fedoraproject.org/wiki/Changes/Cache_Logical_Volumes Anaconda team signed as co-owners of this Change. The dracut team must provide boot support. If dracut does not provide support, cache LVs will not be usable as root devices. This seem to be continuation of https://fedoraproject.org/wiki/Features/SSD_cache and https://fedoraproject.org/wiki/Changes/SSD_cache While the second on targets Fedora 22. Why not merge both Changes? -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, 2014-04-29 at 18:14 +0200, Lennart Poettering wrote: On Tue, 29.04.14 18:03, Alexander Larsson (al...@redhat.com) wrote: systemd = cryptsetup-libs = device-mapper-libs = device-mapper Don't have time to look up the details atm, but iptable was reached via initscripts somehow. I wonder if we can break the d-m-l → d-m link... If we can't there's probably little reason to have two packages for this... Appears to have been introduced in: * Wed Jun 23 2010 Alasdair Kergon a...@redhat.com - 2.02.68-1 - Have device-mapper-libs require device-mapper (circular) for udev rules. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Em 29-04-2014 12:27, Lennart Poettering escreveu: On Tue, 29.04.14 10:37, Daniel J Walsh (dwa...@redhat.com) wrote: On 04/29/2014 06:33 AM, Lennart Poettering wrote: On Mon, 28.04.14 17:01, Daniel J Walsh (dwa...@redhat.com) wrote: The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need. If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images? Lennart Shrinking the the docker image is more then just size. We want to eliminate packages that are not used (Within reason) to eliminate problems like CVE's. If udev/systemd/kmod had a CVE we would need to update all Container images. Well, if you are this principled maybe. But do note that we dont really ship suid binaries (except one binary with fscaps which is systemd-detect-virt), and hence by leaving systemd in the image without running it should result in no increased attack surface that wasn't there anyway... Dead code in the image, that cannot be use to acquire new caps isn't much of a security threat... You're considering only the escalation way to do it, but there are other ways to exploit code laying around, like when some web pages don't sanitize the URL enough and end up allowing executing something in the system, much like sql injection. In those cases, one could craft URLs to run wget or any other tool that may help the intruder get even more inside. It's a pile of faults, yes, but the result isn't good and one good preventive step is keeping the dead/not needed stuff away. Marcelo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Once upon a time, Marcelo Ricardo Leitner marcelo.leit...@gmail.com said: You're considering only the escalation way to do it, but there are other ways to exploit code laying around, like when some web pages don't sanitize the URL enough and end up allowing executing something in the system, much like sql injection. In those cases, one could craft URLs to run wget or any other tool that may help the intruder get even more inside. Down that path lies madness. Are you going to remove /bin/sh? If not, virtually anything else is possible. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Am 29.04.2014 20:51, schrieb Chris Adams: Once upon a time, Marcelo Ricardo Leitner marcelo.leit...@gmail.com said: You're considering only the escalation way to do it, but there are other ways to exploit code laying around, like when some web pages don't sanitize the URL enough and end up allowing executing something in the system, much like sql injection. In those cases, one could craft URLs to run wget or any other tool that may help the intruder get even more inside. Down that path lies madness. Are you going to remove /bin/sh? If not, virtually anything else is possible wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons anything which is not present can't make troubles * security * things get enabeld by bugs * wasted space (keep backups in mind, especially off-site backups) * possible dependecy problems on cloud-systems (to play bullshit-bingo) or simply virtualized infrastructure you pay multiple times for any overhead and if the case happens that you pay for a security problem this is also multiplied that's why on hardened systems mostly customized packages are installed and the most interesting outputs of ./configure --help are the ones starting with --without and --disable signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
Hi, On Tuesday, 29 April 2014 8:59 PM, Dan Williams d...@redhat.com wrote: If NetworkManager is being used, users already don't touch resolv.conf, they edit /etc/sysconfig/network-scripts/ifcfg-* files and use DNS1/DNS2/DNS3 and SEARCHES to set DNS information. Yes, true! If NetworkManager is not being used, then the proposal needs to address what config file users *do* edit to ensure that the upstream DNS servers are pushed to the caching nameserver. If NetworkManager is not used, dnssec-trigger seamlessly handles lot of its responsibilities. I'll update the proposal page with information about it. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tuesday, 29 April 2014 9:29 PM, Paul Wouters p...@nohats.ca wrote: Note that FreeBSD also picked unbound recently for the exact same task. True! - http://www.freebsdnews.net/2013/09/20/freebsd-10s-new-technologies-and-features/ --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Wayland
On Tue, Apr 29, 2014 at 02:04:56PM +0200, Jaroslav Reznik wrote: This change is targeted at F21. For F20, we aim for having an experimental GNOME shell Wayland compositor available, without necessarily having all the surrounding desktop infrastructure ported. To avoid destabilizing the X compositor, mutter will ship two separate libraries, and gnome-shell will ship two binaries that will link against them. Concretely, we plan to have a separate mutter-wayland package. Looks like this hasn't been updated since F20. Should probably give a status report of how these F20 changes went off. Last I looked, gnome-wayland was there, but not terribly functional. --CJD pgpJvzcuap0I0.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Once upon a time, Reindl Harald h.rei...@thelounge.net said: wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons No, the point is that remove a bunch of stuff to 'secure' the system is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example. Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread). -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
Hi, On Tuesday, 29 April 2014 10:08 PM, Andrew Lutomirski l...@mit.edu wrote: but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work. Ah, interesting! Thank you so much for sharing these details. OTOH, it would be straightforward to write a tiny stub that forwards 127.0.0.1:53 to something outside the container. I think this is a better option than having a different device address like 127.0.0.53. Forwarding traffic from inside namespace to a loop-back device on the host is analogous to a guest(VM) forwarding traffic to its host via bridge interface. Thank you. --- Regards -Prasad http://feedmug.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tue, Apr 29, 2014 at 12:17 PM, P J P pj.pan...@yahoo.co.in wrote: Hi, On Tuesday, 29 April 2014 10:08 PM, Andrew Lutomirski l...@mit.edu wrote: but the container itself runs in a network namespace, so it gets its own loopback device. This will mean 127.0.0.1:53 points to the container itself, not the host, so dns resolving in the container will not work. Ah, interesting! Thank you so much for sharing these details. OTOH, it would be straightforward to write a tiny stub that forwards 127.0.0.1:53 to something outside the container. I think this is a better option than having a different device address like 127.0.0.53. Forwarding traffic from inside namespace to a loop-back device on the host is analogous to a guest(VM) forwarding traffic to its host via bridge interface. FWIW, this approach has other benefits. For example, virtme could use it to avoid hacks like trying to bind-mount something on top of /etc/resolv.conf. Some day I hope to propose explicit virtme guest support as a Fedora feature, and, if /etc/resolv.conf were to have constant, predetermined contents, a major wart would go away. https://git.kernel.org/cgit/utils/kernel/virtme/virtme.git --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On 04/29/2014 03:17 PM, Chris Adams wrote: Once upon a time, Reindl Harald h.rei...@thelounge.net said: wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons No, the point is that remove a bunch of stuff to 'secure' the system is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example. Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread). I am looking at this from a tools perspective. If I run an scap tool that says container image XYZ has a vulnerable image of udev, even if udev is not being used, I will have to update the image. If it does not have the package, no reason to update. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Am 29.04.2014 21:17, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons No, the point is that remove a bunch of stuff to 'secure' the system is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example. Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread) simple example: * binary XYZ is vulerable for privilege escalation * we talk about a *local* exploit until now * a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier * a exploit for the web application triggers that binary * voila you have a *remote* privilege escalation to get root access *that* is how attacks can work if things are going wrong you may now come with how likely that happens it's not a matter of how likely, it happened in the past and it will happen in the future and every time such things happened people came with i did not imagine that this could be possible so learn from the past, realize that things are possible and reduce the attack surface for the imaginary you don't believe well, you can ignore that and still pretend that is not security others did that too in many cases learning it the hard way signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.rei...@thelounge.net wrote: simple example: * binary XYZ is vulerable for privilege escalation This makes no sense... * we talk about a *local* exploit until now ...I don't even know what you're trying to say here... * a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier ...and this is already sufficient for a remote exploit. Can we please move all discussion of Zomg! This feature would take an existing security hole and turn it into a security hole with exactly the same impact into its own thread or just stop it entirely? All it does is distract from real discussion. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Firefox Gtk3 test package
Kẏra kxra at riseup.net writes: Martin Stransky stransky at redhat.com writes: How do you enable it? Can you file a BZ# for that at bugzilla.redhat.com? In about:config, set the browser.tabs.remote preference to 'true' More info here: https://wiki.mozilla.org/Electrolysis did you mean the mozilla bug tracker? what product would i file it under at redhat's? There are some patches waiting upstream for review so when those are done. I'd like also update the firefox-gtk3 build to Firefox 31. cool! can you link to bugs / review pages for those patches so that we can track their progress? updating the build to FF31 also sounds great [= So excited to have FF31 now! Thanks again for packaging this. Sadly, I'm still having the same issue with electrolysis (separate processes per tab). Can anyone else test this? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tue, Apr 29, 2014 at 09:29:00AM -0700, Andrew Lutomirski wrote: OTOH, it would be straightforward to write a tiny stub that forwards 127.0.0.1:53 to something outside the container. Is this tiny stub a process running inside the container? What starts that process? What about in the single application docker case where an init system isn't used? -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Am 29.04.2014 21:36, schrieb Andrew Lutomirski: On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.rei...@thelounge.net wrote: simple example: * binary XYZ is vulerable for privilege escalation This makes no sense... for you * we talk about a *local* exploit until now ...I don't even know what you're trying to say here... than google for * privilege escalation * local exploit * remote exploit that could be a good start: http://en.wikipedia.org/wiki/Exploit_%28computer_security%29 * a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier ...and this is already sufficient for a remote exploit. yes, but the difference may be if you only can run unprivileged code or have a chance to own the machine and get root Can we please move all discussion of Zomg! This feature would take an existing security hole and turn it into a security hole with exactly the same impact into its own thread or just stop it entirely? All it does is distract from real discussion can you please start to goole for things others talking about? signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
EPEL Fedora 5 updates-testing report
The following Fedora EPEL 5 Security updates need testing: Age URL 737 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5630/bugzilla-3.2.10-5.el5 192 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-11893/libguestfs-1.20.12-1.el5 72 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0581/augeas-1.2.0-1.el5 20 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1074/cacti-0.8.8b-5.el5 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1096/wordpress-3.8.3-1.el5 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1126/check-mk-1.2.4p2-1.el5 13 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1119/znc-1.2-3.el5 12 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1156/drupal7-7.27-1.el5,drupal6-6.31-1.el5 5 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1229/ndjbdns-1.06-1.el5 3 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1237/prosody-0.8.2-10.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1274/mediawiki119-1.19.15-1.el5 0 https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1278/dmlite-0.6.2-2.el5 The following builds have been pushed to Fedora EPEL 5 updates-testing dmlite-0.6.2-2.el5 mediawiki119-1.19.15-1.el5 perl-Config-Generator-0.7-1.el5 Details about builds: dmlite-0.6.2-2.el5 (FEDORA-EPEL-2014-1278) Common libraries for grid data management and storage Update Information: Patched mistyped parenthesis in Security.cpp dmlite release 0.6.2 dmlite release 0.6.2 dmlite release 0.6.2 dmlite release 0.6.2 ChangeLog: * Fri Apr 25 2014 Alejandro Alvarez aalva...@cern.ch - 0.6.2-2 - Patched mistyped parenthesis in Security.cpp mediawiki119-1.19.15-1.el5 (FEDORA-EPEL-2014-1274) A wiki engine Update Information: == Bugfixes in 1.19.15 == * Fixed resetting passwords. * (bug 58640) Fixed a compatibility issue with PCRE 8.34 that caused pages to appear blank or with missing text. == Security Fixes in 1.19.14 == * (bug 62497) SECURITY: Add CSRF token on Special:ChangePassword. == Bugfixes == * (bug 62467) Set a title for the context during import on the cli. ChangeLog: * Sat Apr 26 2014 Patrick Uiterwijk puiterw...@redhat.com - 1.19.15-1 - Update to 1.19.15 References: [ 1 ] Bug #1081891 - CVE-2014-2665 mediawiki: missing CSRF protection on Special:ChangePassword https://bugzilla.redhat.com/show_bug.cgi?id=1081891 perl-Config-Generator-0.7-1.el5 (FEDORA-EPEL-2014-1276) Shared variables for the Config::Generator modules Update Information: Added an example of a wrapper script in the eg directory. ChangeLog: * Tue Apr 29 2014 Alexandre Beche alexandre.be...@gmail.com 0.7-1 - Added an example of a wrapper script in the eg directory. - Config::Generator::Template: added ifdef() and ifndef() macros. * Thu Mar 27 2014 Alexandre Beche alexandre.be...@gmail.com 0.5-2 - minor change to specfile: Summary and description changed. References: [ 1 ] Bug #1092372 - Upgrade to new upstream version https://bugzilla.redhat.com/show_bug.cgi?id=1092372 ___ epel-devel mailing list epel-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
EPEL Fedora 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing:
Age URL
737
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2012-5620/bugzilla-3.4.14-2.el6
84
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0440/fwsnort-1.6.4-1.el6
79
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0483/boinc-client-7.2.33-3.git1994cc8.el6
69
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-0590/oath-toolkit-2.0.2-4.el6
29
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1011/php-ZendFramework-1.12.5-1.el6
20
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1073/cacti-0.8.8b-5.el6
13
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1102/wordpress-3.8.3-1.el6
13
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1132/check-mk-1.2.4p2-1.el6
13
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1122/knot-1.4.5-1.el6
13
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1137/znc-1.2-3.el6
13
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1144/strongswan-5.1.3-1.el6
12
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1160/drupal7-7.27-1.el6,drupal6-6.31-1.el6
10
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1169/ansible-1.5.5-1.el6
6
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1206/Django14-1.4.11-1.el6
5
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1226/ndjbdns-1.06-1.el6
3
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1236/prosody-0.8.2-7.el6
2
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1254/qt5-qtbase-5.2.1-8.el6
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1275/mediawiki119-1.19.15-1.el6
0
https://admin.fedoraproject.org/updates/FEDORA-EPEL-2014-1282/dmlite-0.6.2-2.el6
The following builds have been pushed to Fedora EPEL 6 updates-testing
dmlite-0.6.2-2.el6
galera-25.3.5-5.el6
geany-1.24.1-1.el6
golang-github-kdar-factorlog-0-0.1.git814d8f7.el6
libsvm-3.18-3.el6
mariadb-galera-5.5.36-10.el6
mediawiki119-1.19.15-1.el6
perl-Config-Generator-0.7-1.el6
python-bitarray-0.3.5-8.el6
python-tw2-forms-2.1.4.1-7.el6
Details about builds:
dmlite-0.6.2-2.el6 (FEDORA-EPEL-2014-1282)
Common libraries for grid data management and storage
Update Information:
Patched mistyped parenthesis in Security.cpp
dmlite release 0.6.2
dmlite release 0.6.2
dmlite release 0.6.2
dmlite release 0.6.2
ChangeLog:
* Fri Apr 25 2014 Alejandro Alvarez aalva...@cern.ch - 0.6.2-2
- Patched mistyped parenthesis in Security.cpp
galera-25.3.5-5.el6 (FEDORA-EPEL-2014-1280)
Synchronous multi-master wsrep provider (replication engine)
Update Information:
Initial build
References:
[ 1 ] Bug #1083232 - Review Request: galera - Galera replication engine
https://bugzilla.redhat.com/show_bug.cgi?id=1083232
geany-1.24.1-1.el6 (FEDORA-EPEL-2014-1270)
A fast and lightweight IDE using GTK2
Update Information:
This update brings the new Geany 1.24.1 to you.
Some highlights:
* Fix bulk Search Replace not to match replacements.
* Update Scintilla to 3.3.6.
* Add experimental GTK3 support.
* Lots of improvements to PHP and Fortran symbols parsing.
* Add filetypes Clojure, CUDA, Batch, Graphviz, PowerShell and Rust.
* Update translations: ca, cs, de, es, eu, fr, gl, he, hu, it, kk, lt, nl, pt,
ru, sk, sl, sv, tr, zh_CN, zh_TW.
A comprehensive list of changes can be found in the ReleaseNotes at
http://www.geany.org/Documentation/ReleaseNotes
A complete list of changes can be found in the ChangeLog at
https://github.com/geany/geany/commits/1.24.1
ChangeLog:
* Thu Apr 17 2014 Dominic Hopf dma...@fedoraproject.org - 1.24.1-1
- New upstream release: Geany 1.24.1
* Tue Apr 15 2014 Dominic Hopf dma...@fedoraproject.org - 1.24-1
- New upstream release: Geany 1.24
- update sqlite3.c.tags and add std.css.tags for CSS3
- fix bogus date warnings
* Fri Jul 26 2013 Ville Skyttä ville.sky...@iki.fi - 1.23.1-2
- Install docs to %{_pkgdocdir} where available.
* Sun May 19 2013 Dominic Hopf
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, Apr 29, 2014 at 03:31:45PM -0400, Daniel J Walsh wrote: On 04/29/2014 03:17 PM, Chris Adams wrote: Once upon a time, Reindl Harald h.rei...@thelounge.net said: wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons No, the point is that remove a bunch of stuff to 'secure' the system is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example. Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread). I am looking at this from a tools perspective. If I run an scap tool that says container image XYZ has a vulnerable image of udev, even if udev is not being used, I will have to update the image. If it does not have the package, no reason to update. Welcome to the wonderful world of containers, ignoring 20 years of shipping software in Linux distributions! -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Am 29.04.2014 21:31, schrieb Daniel J Walsh: On 04/29/2014 03:17 PM, Chris Adams wrote: Once upon a time, Reindl Harald h.rei...@thelounge.net said: wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons No, the point is that remove a bunch of stuff to 'secure' the system is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example. Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread). I am looking at this from a tools perspective. If I run an scap tool that says container image XYZ has a vulnerable image of udev, even if udev is not being used, I will have to update the image. If it does not have the package, no reason to update exactly *that* is the problem people never had to work the one or other way in security business not understanding if you have external security audits there is no can this be a problem you finally get fix that within 24 hours or shutdown with no choice been there and while 100% sure the audit result is from the category a fool with a tool is still a fool no choice to ignore it and god beware you manage to explain that it is not relevant followed by a real exploit two days later signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Once upon a time, Reindl Harald h.rei...@thelounge.net said: simple example: * binary XYZ is vulerable for privilege escalation A local, non-privileged binary cannot be vulerable for privilege escalation. If I can run a non-privileged binary to escalate, then there is a problem with some other part of the system, not the binary. I can (unless severely locked down, which is difficult-to-impossible to do in practice) download another non-privileged binary and achieve the same privilege escalation. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, Apr 29, 2014 at 12:48 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 29.04.2014 21:36, schrieb Andrew Lutomirski: On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.rei...@thelounge.net wrote: simple example: * binary XYZ is vulerable for privilege escalation This makes no sense... for you * we talk about a *local* exploit until now ...I don't even know what you're trying to say here... than google for * privilege escalation * local exploit * remote exploit that could be a good start: http://en.wikipedia.org/wiki/Exploit_%28computer_security%29 * a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier ...and this is already sufficient for a remote exploit. yes, but the difference may be if you only can run unprivileged code or have a chance to own the machine and get root Can you give an actual concrete example of wtf you're talking about? Because I suspect that you're completely wrong, but maybe you're right and no one on this thread understands what you're trying to say. Feel free to say things like suppose I have a php app that does XYZ and feel free to add supposedly vulnerable udev binaries, copies of sh, copies of busybox, copies of python, gcc, etc, as needed for this to make any sense. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
- Original Message - = Proposed System Wide Change: Default Local DNS Resolver = https://fedoraproject.org/wiki/Changes/Default_Local_DNS_Resolver Change owner(s): P J P p...@fedoraproject.org, Pavel Šimerda pav...@pavlix.net, Tomas Hozza tho...@redhat.com Ops, I was just pinged by Pavlix that the team planned this Change for F22 time- frame but I still live in the flood of F21 Changes and missed it. So the current state is - this Change targets Fedora 22 but most of the development should land into Fedora 21 - not enabled by default - to get test coverage. To make sure this Change is in the state it could be shipped in the release as default, corner cases has to be identified and worked on, there's also NetworkManager integration that has to happen. I'm sorry for confusion. Jaroslav To install a local DNS resolver trusted for the DNSSEC validation running on 127.0.0.1:53. This must be the only name server entry in /etc/resolv.conf. The automatic name server entries received via dhcp/vpn/wireless configurations should be stored separately, as transitory name servers to be used by the trusted local resolver. In all cases, DNSSEC validation will be done locally. This change was submitted after the Submission deadline. == Detailed Description == There are growing instances of discussions and debates about the need for a trusted DNSSEC validating local resolver running on 127.0.0.1:53. There are multiple reasons for having such a resolver, importantly security usability. Security protection of user's privacy becomes paramount with the backdrop of the increasingly snooping governments and service providers world wide. People use Fedora on portable/mobile devices which are connected to diverse networks as and when required. The automatic DNS configurations provided by these networks are never trustworthy for DNSSEC validation. As currently there is no way to establish such trust. Apart from trust, these name servers are often known to be flaky and unreliable. Which only adds to the overall bad and at times even frustrating user experience. In such a situation, having a trusted local DNS resolver not only makes sense but is in fact badly needed. It has become a need of the hour. (See: [1], [2], [3]) Going forward, as DNSSEC and IPv6 networks become more and more ubiquitous, having a trusted local DNS resolver will not only be imperative but be unavoidable. Because it will perform the most important operation of establishing trust between two parties. All DNS literature strongly recommends it. And amongst all discussions and debates about issues involved in establishing such trust, it is unanimously agreed upon and accepted that having a trusted local DNS resolver is the best solution possible. It'll simplify and facilitate lot of other design decisions and application development in future. (See: [1], [2], [3]) People:- * Petr Spacek * Paul Wouters * Simo Sorce * Dmitri Pal * Carlos O'Donell == Scope == * Proposal owners: Proposal owners shall have to ** define the syntax and semantics for new configuration parameters/files. ** persuade and coordinate with the other package owners to incorporate new changes/workflow in their applications. * Other developers: (especially NetworkManager and the likes) ** would have to implement the new features/workflow for their applications adhering to the new configurations and assuming the availability of the '''trusted''' local DNS resolver. ** NetworkManager already has features capability to support local DNS resolvers. Though few details are still under development, but are expected to realize in near future. Please see [4] * Release engineering: ** would have to ensure that trusted local DNS resolver is available throughout the installation stage and the same is installed on all installations including LiveCDs etc. * Policies and guidelines: ** the chosen trusted DNS resolver package(ex dnsmasq or dnssec-trigger etc.) would have to ensure that their DNS resolver starts at boot time and works out of the box without any user intervention. ** NetworkManager and others would have to be told to not tamper with the local nameserver entries in '/etc/resolv.conf' and save the dynamic nameserver entries in a separate configuration file. [1] https://www.ietf.org/mail-archive/web/dane/current/msg06469.html [2] https://www.ietf.org/mail-archive/web/dane/current/msg06658.html [3] https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html [4] https://lists.fedoraproject.org/pipermail/devel/2014-April/197848.html ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct:
[389-devel] please review: Ticket 47777 - attribute uniqueness plugin fails when set as a chaining component
https://fedorahosted.org/389/ticket/4 https://fedorahosted.org/389/attachment/ticket/4/0001-Ticket-4-attribute-uniqueness-plugin-fails-when-.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Am 29.04.2014 21:59, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: simple example: * binary XYZ is vulerable for privilege escalation A local, non-privileged binary cannot be vulerable for privilege escalation. If I can run a non-privileged binary to escalate, then there is a problem with some other part of the system, not the binary. I can (unless severely locked down, which is difficult-to-impossible to do in practice) download another non-privileged binary and achieve the same privilege escalation don't get me wrong but you are talking bullshit you can't download whatever you like to do in any random situation and excutue it like in a sehll - if you have only *one command* through a web application you need to achieve that this single command triggers the whole attack surface down to the critical component giving you root access you simply ignore the history of nearly any package coming with security updates and CVE's where it's often even hard to believe how can this small piece have any security problem at all Am 29.04.2014 22:04, schrieb Andrew Lutomirski: Can you give an actual concrete example of wtf you're talking about? Because I suspect that you're completely wrong, but maybe you're right and no one on this thread understands what you're trying to say. no i can't give you and example which replaces bother for more than a decade in case of security in a single mailing-list thread frankly feel free to ignore what people are telling you these people continue also to feel free remove anything un-needed from systems at the end of the day we will se who was right - the people tyring to make things as secure as possible or the ones which would even not realize a root-exploit on their machines after it has happened because in doubt you have no chance to face it (given that the first thing a rootkit is doing is to manipulate system-commands to hide itself) signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Once upon a time, Reindl Harald h.rei...@thelounge.net said: don't get me wrong but you are talking bullshit Put up or shut up. you can't download whatever you like to do in any random situation and excutue it like in a sehll - if you have only *one command* through a web application you need to achieve that this single command triggers the whole attack surface down to the critical component giving you root access If you can't explain how a non-privileged binary can result in a privilege escalation, then you are wrong. You need to go up-thread and read what I was responding to and show how it is wrong. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Am 29.04.2014 22:22, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: don't get me wrong but you are talking bullshit Put up or shut up i shut when i say - not when you say https://www.google.com/search?q=local+root+exploit+CVE google as example for CVE-2014-0038 and as i already explained you: a attacker has no shell, you have two ways to force a existing local exploit by a web-application: A: try to get a complete script on the machine and execute it B: find a very likely present binary and bring it to do the rest of the attack for you with arbitary input if you find B it's much easier because pass unsanitized input to a web-script calling system() with it is one thing, find a way to create a local file with whatever input you like and execute it finally is a complete different world and needs much more than one security problem in the web-application you can't download whatever you like to do in any random situation and excutue it like in a sehll - if you have only *one command* through a web application you need to achieve that this single command triggers the whole attack surface down to the critical component giving you root access If you can't explain how a non-privileged binary can result in a privilege escalation, then you are wrong. You need to go up-thread and read what I was responding to and show how it is wrong. in case it don't sanitize user input, calling a already running privileged process and feed it with arbitary input damend do you really pretend that never happened in the past? and no i do not get paied to seek archives for you! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, Apr 29, 2014 at 4:16 PM, Reindl Harald h.rei...@thelounge.netwrote: don't get me wrong but you are talking bullshit Reindl, your SNR is way way high. Maybe try sending /less/ emails, concentrating in being clear and helpful? Don't worry, there is _always_ someone who's wrong on the internet. You can't address all of them... keep in mind, in some cases you are the one who isn't fully understanding the topic... cheers, m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Orphaning spectrum in Fedora
That’s spectrum1 which has been long dead upstream, and there is no further development in upstream (for spectrum2 which would be a replacement), so I don't want to drag it further. I’ll keep it in EPEL 5,6 and if any bug happens, I’ll patch it. Any takers? Yeah, I thought so Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Em 29-04-2014 17:04, Andrew Lutomirski escreveu: On Tue, Apr 29, 2014 at 12:48 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 29.04.2014 21:36, schrieb Andrew Lutomirski: On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.rei...@thelounge.net wrote: simple example: * binary XYZ is vulerable for privilege escalation This makes no sense... for you * we talk about a *local* exploit until now ...I don't even know what you're trying to say here... than google for * privilege escalation * local exploit * remote exploit that could be a good start: http://en.wikipedia.org/wiki/Exploit_%28computer_security%29 * a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier ...and this is already sufficient for a remote exploit. yes, but the difference may be if you only can run unprivileged code or have a chance to own the machine and get root Can you give an actual concrete example of wtf you're talking about? Because I suspect that you're completely wrong, but maybe you're right and no one on this thread understands what you're trying to say. Feel free to say things like suppose I have a php app that does XYZ and feel free to add supposedly vulnerable udev binaries, copies of sh, copies of busybox, copies of python, gcc, etc, as needed for this to make any sense. In simple terms: when you go to sleep at night, do you leave your toolbox right in front of your locked front door, ready for anyone to use it on your door? I do hope not, and that's the point in here. Or you're just too naive to believe that the street wall is just enough to hide it and nothing else is needed. Ohh but you remove X while program Y can also be used! Yes, it can! But makes it harder, that's the point. Can bash open tcp sockets? Yes. Bash can pass through proxies easily? No. But wget can. Ohh but then someone also needs the proxy information Yes, and that's not the point here. You already have 1 obstacle more. You have to think out of the box here, we're brainstorming on why a toolbox in your front door may or not be a liability. Security is way much more than privilege escalation. You are not considering that someone may be able to trigger an event and simply start a DoS, due to systemd or whatever in question not being properly initialized. Exposing this theoretical trigger here to you so you understand it, right now, it out of scope. I hope you understand that. Marcelo -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Once upon a time, Reindl Harald h.rei...@thelounge.net said: google as example for CVE-2014-0038 and as i already explained you: a attacker has no shell, you have two ways to force a existing local exploit by a web-application: A: try to get a complete script on the machine and execute it B: find a very likely present binary and bring it to do the rest of the attack for you with arbitary input If I can run arbitrary code as your web user, I can do whatever your web user can do. If your kernel has a security hole, I can exploit that. If I can run PHP code, there's a million things that I can do. If I can run shell code, I can do just about as much. How does the existence of a non-privileged systemd binary affect that? I understand defense in depth, I just don't believe the existence of a non-privileged systemd binary has a non-negligible effect on system (or container in this case) security. If I can run an arbitrary binary on your system, you are already owned. I can run /bin/sh (for example, just because it is nearly universal) and fetch other arbitrary binaries. Do some binaries being available possibly make an attack easier? Maybe, but that work is generally figured out once by smart people, and then exploited a million times by script kiddies. Something being harder doesn't add anything mcuh to security, because it _can_ be figured out, will be, and then it'll be copypasted repeatedly (and you haven't gained a significant advantage from it is harder). -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Default Local DNS Resolver
On Tue, Apr 29, 2014 at 12:41 PM, Matthew Miller mat...@fedoraproject.org wrote: On Tue, Apr 29, 2014 at 09:29:00AM -0700, Andrew Lutomirski wrote: OTOH, it would be straightforward to write a tiny stub that forwards 127.0.0.1:53 to something outside the container. Is this tiny stub a process running inside the container? What starts that process? What about in the single application docker case where an init system isn't used? No clue. What sets /etc/resolv.conf right now? FWIW, how many single applications actually work correctly when run as PID 1? I suspect that, eventually, Docker will end up with a specialized PID 1 even for single applications. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Am 29.04.2014 23:00, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: google as example for CVE-2014-0038 and as i already explained you: a attacker has no shell, you have two ways to force a existing local exploit by a web-application: A: try to get a complete script on the machine and execute it B: find a very likely present binary and bring it to do the rest of the attack for you with arbitary input If I can run arbitrary code as your web user, I can do whatever your web user can do limited (why limited goes way too off-topic) If your kernel has a security hole, I can exploit that surely, the point is how easy i can do that, do the instructions somewhere how to do that work or not because they contain a command / binary not available on the target system If I can run PHP code, there's a million things that I can do. If I can run shell code, I can do just about as much. How does the existence of a non-privileged systemd binary affect that? given index.php?dumb_param=exploit_code dumb_param gives exploit_code to shell_exec() or like function you can't do whatever you like here simply be escaping so you are very limited with your command finally you need a abstraction in form of a binary doing harm with the input which you can't pass directly to shell_exec limited by input quoting I understand defense in depth good I just don't believe the existence of a non-privileged systemd binary has a non-negligible effect on system (or container in this case) security. If I can run an arbitrary binary on your system, you are already owned. I can run /bin/sh (for example, just because it is nearly universal) and fetch other arbitrary binaries. as explained you can't do that in any situation Do some binaries being available possibly make an attack easier? Maybe, but that work is generally figured out once by smart people, and then exploited a million times by script kiddies. Something being harder doesn't add anything mcuh to security, because it _can_ be figured out, will be, and then it'll be copypasted repeatedly (and you haven't gained a significant advantage from it is harder) surely because the copypasted instrcution may not work if it relies on a default binary not installed in the container in that case the attacker needs to adopt the exploit only for you or he just goes to a server where his exploit code works out of the box signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, Apr 29, 2014 at 1:57 PM, Marcelo Ricardo Leitner marcelo.leit...@gmail.com wrote: Em 29-04-2014 17:04, Andrew Lutomirski escreveu: On Tue, Apr 29, 2014 at 12:48 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 29.04.2014 21:36, schrieb Andrew Lutomirski: On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.rei...@thelounge.net wrote: simple example: * binary XYZ is vulerable for privilege escalation This makes no sense... for you * we talk about a *local* exploit until now ...I don't even know what you're trying to say here... than google for * privilege escalation * local exploit * remote exploit that could be a good start: http://en.wikipedia.org/wiki/Exploit_%28computer_security%29 * a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier ...and this is already sufficient for a remote exploit. yes, but the difference may be if you only can run unprivileged code or have a chance to own the machine and get root Can you give an actual concrete example of wtf you're talking about? Because I suspect that you're completely wrong, but maybe you're right and no one on this thread understands what you're trying to say. Feel free to say things like suppose I have a php app that does XYZ and feel free to add supposedly vulnerable udev binaries, copies of sh, copies of busybox, copies of python, gcc, etc, as needed for this to make any sense. In simple terms: when you go to sleep at night, do you leave your toolbox right in front of your locked front door, ready for anyone to use it on your door? I do hope not, and that's the point in here. Or you're just too naive to believe that the street wall is just enough to hide it and nothing else is needed. The bad guys have their own tools. Ohh but you remove X while program Y can also be used! Yes, it can! But makes it harder, that's the point. Can bash open tcp sockets? Yes. Bash can pass through proxies easily? No. But wget can. Ohh but then someone also needs the proxy information Yes, and that's not the point here. You already have 1 obstacle more. If you want to go down that path, set up selinux to prevent execing things that oughtn't to be execed. But trying to prevent exploits from working by removing every possible helper from the path is a losing proposition and is just not worth doing. You have to think out of the box here, we're brainstorming on why a toolbox in your front door may or not be a liability. Security is way much more than privilege escalation. You are not considering that someone may be able to trigger an event and simply start a DoS, due to systemd or whatever in question not being properly initialized. Exposing this theoretical trigger here to you so you understand it, right now, it out of scope. I hope you understand that. Sorry, wrong. Systemd *isn't running*, so you can't trigger an event. --Andy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Am 29.04.2014 23:09, schrieb Andrew Lutomirski: If you want to go down that path, set up selinux to prevent execing things that oughtn't to be execed. But trying to prevent exploits from working by removing every possible helper from the path is a losing proposition and is just not worth doing defense in depth means you are doing *both* defense in depth means limit the attack surface as much as you can defense in depth means place security layers behind others to surive a failing one defense in depth means disable and remove anything which is not needed for your tasks signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Once upon a time, Reindl Harald h.rei...@thelounge.net said: defense in depth means limit the attack surface as much as you can No, because as much as you can is turn the system off and bury it in concrete (with an armed guard). The goal is as much as practical. Trying to remove things that are needed is not practical. Spending a whole bunch of effort to allow you to remove systemd (again, just the files, it isn't running) seems excessive. There are some basic things that RPMs expect; installing a service expects that the service management tools are present. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Am 29.04.2014 23:20, schrieb Chris Adams: Once upon a time, Reindl Harald h.rei...@thelounge.net said: defense in depth means limit the attack surface as much as you can No, because as much as you can is turn the system off and bury it in concrete (with an armed guard). The goal is as much as practical. Trying to remove things that are needed is not practical ok, now it is proven that you only try to quibbling * the system needs to do a job * turn it off means pretty clear it can't do it's job * as much as you can means pretty clear not stop it's job you can't tun it off because it's not practical however, thank you to show me that any discussion with you is worthless because you are more interested in words than in their content and maybe be proud to be an native english speaker - congratulaitions for that but it won't help that much at the end of the day signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald h.rei...@thelounge.netwrote: defense in depth means limit the attack surface as much as you can As folks are trying to point out to you, these principles are well understood in this group. However, _any minimally usable environment will have a scripting engine_ -- /bin/sh, python, and having _any_ of those general purpose tools available is enough for the attacker. On your own machines, you might gain some (limited) advantage removing some of them. Fedora and its derivatives, OTOH, are a large enough target that it's worth for attackers to tailor attacks to it. So removing some tools won't do much, and removing _all_ tools will ruin everyone's day. m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
Once upon a time, Reindl Harald h.rei...@thelounge.net said: however, thank you to show me that any discussion with you is worthless Right back at you. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
On Tue, Apr 29, 2014 at 5:28 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Reindl Harald h.rei...@thelounge.net said: however, thank you to show me that any discussion with you is worthless Right back at you. The CoC does say a few things on this topic. I am finding Reindl's trollish behavior extremely annoying. In my reading, 1% of his emails have some value, 99% are just winding people up :-( Is there a cool down box available? m -- martin.langh...@gmail.com - ask interesting questions - don't get distracted with shiny stuff - working code first ~ http://docs.moodle.org/en/User:Martin_Langhoff -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
kernel packaging split up landing in Rawhide
Hi All, As part of the F21 Modular Kernel Packaging for Cloud Feature[1], I've committed and pushed the kernel packaging split up into kernel-core and kernel-drivers subpackages. For those of you running rawhide, this really shouldn't be a major impact at all. When you do a yum update, you will see kernel, kernel-core, and kernel-drivers packages being installed. The end result should be in line with today's rawhide kernels. Note: Unless you're using a typical VM or Cloud image, don't uninstall the kernel or kernel-drivers packages. The machine may boot with just kernel-core, but it will lack drivers for a significant portion of bare-metal hardware without kernel-drivers installed. Despite best efforts in testing, it's always possible a bug or two snuck through. In the event that you do have an issue with this, please file a bug against the kernel package. josh [1]https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
