Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 22.03.2014 03:21, schrieb Lennart Poettering:
> On Sat, 22.03.14 01:20, Miloslav Trmač (m...@volny.cz) wrote:
>> DNS queries can't really be done within the firewall (and due to the
>> circular dependency between having the firewall up before allowing access
>> to the network and needing access to the network to resolve DNS names, they
>> can't even be used in the on-disk firewall configuration).  Having a single
>> centralized name->IP address repository instead of having a redundant copy
>> in each host, and having the configuration use readable names instead of IP
>> addresses, makes some difference in usability and management overhead.
> 
> This is supposedly security functionality. You shouldn't build your
> security functionality on top of DNS. If you do, then you gain no
> security

in your world one thing rules all true
in the world of *layered* security not true



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 22.03.2014 03:05, schrieb Lennart Poettering:
> On Fri, 21.03.14 23:35, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>>> In other words you are telling us that now to get something implemented or 
>>> removed in Fedora we have to not only
>>> deal with our usual politics and bureaucracy but also all the downstream 
>>> distribution to us as well...
>>
>> no, in other words he told you that whe world is not turning around
>> a few people deperecating anything which does not get a update for
>> the sake of a update and what some people calling  "legacy" might
>> be things not needing updates because they just works and update
>> and replace/drop for the sake of a change does not make things
>> better for no good reason
>>
>> the author of tcpwrapper is Wietse Venema, the perosn who created
>> and maintains postfix - frankly if only 1% of the software out
> 
> So, you do realise that the same Wietse Venema who wrote and then
> stopped maintaining tcpwrappers is the one who didn't add *any*
> tcpwrappers support to Postfix? To this day Postfix doesn't do
> tcpwrappers. Probably for a good reason, don't you think?

until you managed the same stability of interfaces for a couple
of years like postfix don't strip quotes

>> most of the replacements in the last few years could have been
>> becakward compatible if the developers would not be too lazy
>> to care about
> 
> Wietse is such a lazy person that he didn't had hosts.allow/.deny
> compatibility support to Postfix, isn't he?

ask him why



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 22.03.2014 03:07, schrieb Lennart Poettering:
> On Fri, 21.03.14 23:46, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> if you believe it or not: there exists code which don't neeed
>> updates and reweites all te time because it just works and given
> 
> You do realize that if software engineering has shown something then
> yes, software development is never finished, it's a process. You do need
> maintains for such things

i do not need maintains for things just working
you do because it's your passion to replace, change and deprecate

many others and i need working systems to do my work on them






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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Miloslav Trmač]

2014-03-20 18:59 GMT+01:00 Paul Wouters :

> On Thu, 20 Mar 2014, Lennart Poettering wrote:
>
>  I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
>> Fedora.
>>
>
> I'd be happy to see those go.
>
> Those who depend on it though, should see some "failed closed"
> behaviour, so their service does not suddenly become more exposed.
>

Wouldn't failing closed essentially involve keeping libwrap, keeping all
the callers, keeping the existing parser, only ignoring most of the rule
and treating any rule matching the daemon name as DENY?  At that point we
might just as well keep the non-controversially-safe functionality like IP
checks working.
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: Java 8

[Miloslav Trmač]

2014-03-21 13:11 GMT+01:00 Jaroslav Reznik :

> = Proposed System Wide Change: Java 8 =
> https://fedoraproject.org/wiki/Changes/Java8
>


> == Detailed Description ==
> OpenJDK8 is much more strict when it comes to building javadocs. Many -
> javadoc package in Fedora fail to build. Those that are built should
> continue
> working just fine.
>

(selective quoting)

> == Scope ==
> * Proposal owners:
> ** In case of a mass rebuild, supply/apply patches to fix build against
> OpenJDK
> 8
> * Other developers:
> ** Other java packagers will need to apply patches to their java package to
> ensure they can build against OpenJDK 8
> ** Everyone will need to test packages to verify that they work against
> OpenJDK 8
>
> * Release engineering:
> ** Possibly mass-rebuild (?) all Java packages. This is not strictly
> required
> to make OpenJDK 8 the default Java runtime.
>

Given the known large number of failures (OptionalJavadocs says "80% build
failure rate" without saying that all are JavaDoc-related), we really
should do a mass rebuild to identify which packages fail to build *and* to
file bugs soonish, instead of waiting for a Fedora-wide mass rebuild and
then scrambling to fix dozens/hundreds of build failures in to avoid
slipping the schedule.  We don't necessarily need an official one, perhaps
only in a never-to-be-merged side tag (or even scratch builds?)
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Miloslav Trmač]

2014-03-22 5:20 GMT+01:00 Miloslav Trmač :

> I'm participating in this discussion because, as a general rule, I assume
> most administrators configuring security, and most users in general, *aren't
> idiots*.  So, the fairly large number of assumed non-idiots using this
> functionality suggests, as a first approximation to truth, that it is
> useful, and it's the few of us that discuss removal of the feature that are
> wrong about the consequences of our actions.
>

... and this equally applies to all the programmers who wrote servers that
don't call tcp_wrappers but provide similar DNS-based policy mechanisms.
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Miloslav Trmač]

2014-03-22 3:21 GMT+01:00 Lennart Poettering :

> On Sat, 22.03.14 01:20, Miloslav Trmač (m...@volny.cz) wrote:
>
> > > Well, if you filter in postfix or ssh, then you have a domain-specific,
> > > powerful language there. You can not only match on source addresses,
> but
> > > also on user names, groups, authentication methods, connection features
> > > SASL schemes, crypto algorithms, ... It's a very good thing being able
> > > to control this in a unified, but domain-specific way.
> >
> > What's "unified" about that?
>
> Isn't that obvious? You have a single language that centralizes your
> access decisions in one place


I see what you mean now.  There are two mutually exclusive dimensions to
unify here (same for all servers / everything for one server); so it is
unordered which one is "more unified".


This is supposedly security functionality. You shouldn't build your
> security functionality on top of DNS. If you do, then you gain no
> security.
>

I have made a careful argument (quoted below).  Feel free to refute that
argument with specific objections instead of general guidelines like "you
shouldn't use DNS" that border on cargo-cult security.


> > Also, note that an organization *can* actually make DNS sufficiently
> secure
> > by using their own DNS servers that have authoritative sources for the
> > relevant domains, even without DNSSEC: this would keep out all script
> > kiddies and internet-originating attackers who can't attack the link
> > between the tcp_wrappers user and the DNS server, while still allowing
> > attacks from a compromised computer within the organization--which is
> > *exactly* the case where the domain-specific configuration would probably
> > allow access *anyway*, so the attacker might have nothing to gain by
> > subverting DNS.  (Yes, there are many possible configurations of
> > tcp_wrappers where this argument does not apply, and it does require care
> > from the administrators of the system.)
>
> And you honestly believe that people who are capable enough of setting
> up DNS locally and across the company in a secure way to do something
> like this,


The design I have described does not require *an*y special effort to secure
DNS; no DNSSec, no VPNs, no nothing.  Just use ordinary wired Ethernet, and
WPA2 for your WiFi, the way everyone already does.  (The trouble with this
design is not that it is difficult to set up, but that it doesn't mean
every possible configuration that uses DNS is reliable.)

Specifically, basically any small business with a single internal network
and a single Linux do-it-all box (which includes a DNS server for the
internal network) can AFAICT quite safely use tcp_wrappers to restrict
access to some services of the server to the internal network.


are also crazy enough to do their access control with tcpwrap
> rather maybe firewalls and basically every other possibility?
>

Saying that they would be crazy to use it in a thread that is explicitly
discussing whether there are reasonable uses is circular reasoning.

You guys claim on one hand that tcpwrap is wonderfully designed and
> super-easy to use.
>

I don't remember anybody claiming that; paying a little more attention to
what people are actually saying might help mutual understanding.


> We *do* need to *actually understand* the user's motivations for using
> > tcp_wrappers, not just dismiss it as security theater--because even if it
> > *were* security theater, if we don't know why the users are doing this
> they
> > are likely to do it in the new system as well, and we will end up with
> even
> > a bigger mess implementing the same security theater.
>
> We *do* know that tcpd is 70% insecure non-sense, 100% crappy code, and
> about 30% logic that is much better, safer, and more comprehensively
> implemented in a firewall.
>

I'm not in this thread to discuss technical merits of the existing
implementation.  It may be 100% crappy code.  *All* of what you say above
may be true, but that being true about a widely-used feature *doesn't
automatically mean that eliminating the feature increases securit*y.

I'm not even in this thread to object to doing extra work to break users'
systems, because you may be right that most users of tcp_wrappers that use
it for the DNS functionality shouldn't, and it might be irresponsible for
us to support such configurations.

I'm participating in this discussion because, as a general rule, I assume
most administrators configuring security, and most users in general, *aren't
idiots*.  So, the fairly large number of assumed non-idiots using this
functionality suggests, as a first approximation to truth, that it is
useful, and it's the few of us that discuss removal of the feature that are
wrong about the consequences of our actions.


If this is being used (and AFAICT it is), then the users have a reason.
Per the general rule, that reason is likely to be right for their
situation; and even if they shouldn't be using it, their thought process is
likely 

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Eric Smith]

On Fri, Mar 21, 2014 at 8:07 PM, Lennart Poettering wrote:

> You do realize that if software engineering has shown something then
> yes, software development is never finished, it's a process. You do need
> maintains for such things.
>

The software in my microwave oven, coffee maker, thermostat, DVD player,
stereo receiver, and many processors in my car (including engine control,
antilock brakes, and many others) is quite definitely finished.  That's not
to say that there aren't any bugs, but the vendors aren't sending me any
updated versions.  That's an existence proof that software *can* be "good
enough" and not need updates.  Granted, most software is not "good enough",
but the lack of updates to a piece of software is not sufficient to
establish a priori that the software should be discarded.
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Miloslav Trmač]

2014-03-22 3:07 GMT+01:00 Lennart Poettering :

> On Fri, 21.03.14 23:46, Reindl Harald (h.rei...@thelounge.net) wrote:
>
> > if you believe it or not: there exists code which don't neeed
> > updates and reweites all te time because it just works and given
>
> You do realize that if software engineering has shown something then
> yes, software development is never finished, it's a process. You do need
> maintains for such things.
>

Fedora does have a maintainer for the package, AFAICT sufficiently active.
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Sat, 22.03.14 01:20, Miloslav Trmač (m...@volny.cz) wrote:

> > Well, if you filter in postfix or ssh, then you have a domain-specific,
> > powerful language there. You can not only match on source addresses, but
> > also on user names, groups, authentication methods, connection features
> > SASL schemes, crypto algorithms, ... It's a very good thing being able
> > to control this in a unified, but domain-specific way.
> 
> What's "unified" about that?

Isn't that obvious? You have a single language that centralizes your
access decisions in one place and opens up to you a variety of
credentials from all layers of the stack. And not just IP range
decisions...

> DNS queries can't really be done within the firewall (and due to the
> circular dependency between having the firewall up before allowing access
> to the network and needing access to the network to resolve DNS names, they
> can't even be used in the on-disk firewall configuration).  Having a single
> centralized name->IP address repository instead of having a redundant copy
> in each host, and having the configuration use readable names instead of IP
> addresses, makes some difference in usability and management overhead.

This is supposedly security functionality. You shouldn't build your
security functionality on top of DNS. If you do, then you gain no
security. 

> Also, note that an organization *can* actually make DNS sufficiently secure
> by using their own DNS servers that have authoritative sources for the
> relevant domains, even without DNSSEC: this would keep out all script
> kiddies and internet-originating attackers who can't attack the link
> between the tcp_wrappers user and the DNS server, while still allowing
> attacks from a compromised computer within the organization--which is
> *exactly* the case where the domain-specific configuration would probably
> allow access *anyway*, so the attacker might have nothing to gain by
> subverting DNS.  (Yes, there are many possible configurations of
> tcp_wrappers where this argument does not apply, and it does require care
> from the administrators of the system.)

And you honestly believe that people who are capable enough of setting
up DNS locally and across the company in a secure way to do something
like this, are also crazy enough to do their access control with tcpwrap
rather maybe firewalls and basically every other possibility?

Or, maybe there are people like that, there's always somebody crazy
enough for everything. But then the question is: should our product be a
toolbox with lots of crappy tools who are excessively hard to use in a
secure way, even though they are supposedly security tools, only useful
for extraordinarily capable administrators, who know exactly what they
have to make of them, and know that their supposedly "simple"
configuration files are really insecure unless you also are willing to
set up a massively complicated infrastructure of DNSSEC or otherwise
secured links so that nobody can poison your DNS?

You guys claim on one hand that tcpwrap is wonderfully designed and
super-easy to use. On the other hand you advise people using it to set
up DNSSEC, secured links and whatnot... So what is it now? Secure? Not
secure? Easy to setup? Difficult to set up?

> We *do* need to *actually understand* the user's motivations for using
> tcp_wrappers, not just dismiss it as security theater--because even if it
> *were* security theater, if we don't know why the users are doing this they
> are likely to do it in the new system as well, and we will end up with even
> a bigger mess implementing the same security theater.

We *do* know that tcpd is 70% insecure non-sense, 100% crappy code, and
about 30% logic that is much better, safer, and more comprehensively
implemented in a firewall.

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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Fri, 21.03.14 23:46, Reindl Harald (h.rei...@thelounge.net) wrote:

> if you believe it or not: there exists code which don't neeed
> updates and reweites all te time because it just works and given

You do realize that if software engineering has shown something then
yes, software development is never finished, it's a process. You do need
maintains for such things.

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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Fri, 21.03.14 23:35, Reindl Harald (h.rei...@thelounge.net) wrote:

> > In other words you are telling us that now to get something implemented or 
> > removed in Fedora we have to not only
> > deal with our usual politics and bureaucracy but also all the downstream 
> > distribution to us as well...
> 
> no, in other words he told you that whe world is not turning around
> a few people deperecating anything which does not get a update for
> the sake of a update and what some people calling  "legacy" might
> be things not needing updates because they just works and update
> and replace/drop for the sake of a change does not make things
> better for no good reason
> 
> the author of tcpwrapper is Wietse Venema, the perosn who created
> and maintains postfix - frankly if only 1% of the software out

So, you do realise that the same Wietse Venema who wrote and then
stopped maintaining tcpwrappers is the one who didn't add *any*
tcpwrappers support to Postfix? To this day Postfix doesn't do
tcpwrappers. Probably for a good reason, don't you think?

> most of the replacements in the last few years could have been
> becakward compatible if the developers would not be too lazy
> to care about

Wietse is such a lazy person that he didn't had hosts.allow/.deny
compatibility support to Postfix, isn't he?

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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Fri, 21.03.14 20:02, Florian Weimer (f...@deneb.enyo.de) wrote:

> * Lennart Poettering:
> 
> >> So offer something with equivalent functionality (and config file
> >> syntax compatibility), with a nice modern clean API and then systemd
> >> and others can be moved over to that 1 by 1, and once we've no more
> >> users left we can kill of the old beast ?
> >
> > Nope. In systemd we already support one subsystem for filtering just
> > fine, it's called a firewall.
> 
> Does this subsystem support DNS-based rules?

No, firewalls don't do DNS-based filtering, since it's a security nightmare.

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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Miloslav Trmač]

2014-03-21 14:46 GMT+01:00 Dennis Jacobfeuerborn :

> As I perceive it one of the biggest problems for Fedora as a development
> platform for new technologies is that everything is tied to very rigorous
> guidelines and controls that tend to be fairly conservative. This is great
> when you care about overall stability and coherence of the platform but
> terrible if you want to enable people to use Fedora as a platform to
> spearhead new technologies.
>
> One example is the policy that patches for packages should first be
> submitted and accepted upstream before they make it into Fedora. This works
> great because that way you can ensure that once features are added in
> Fedora it is unlikely that they have to be removed later again because they
> are rejected upstream. It's terrible though if you want to live on the
> bleeding edge. Take for example the networking features of OpenStack that
> required kernel changes that weren't yet committed upstream or the fact
> that Docker required AUFS for a long time. In both cases Fedora was a
> terrible platform to develop these technologies because of its conservative
> stance.
>

Well, a distribution is an *integration* project.  Everyone is perfectly
free to replace individual components with HEAD checkouts, or the
equivalent copr RPMs, to be able to develop such bleeding-edge software;
but that doesn't automatically mean that the millions of Fedora users
should have the same bleeding-edge software imposed on them just so that
the developers of that specific project have an easier time.

For users, Fedora really should include and promote software that is
*past*the bleeding-edge state, something that we can honestly
recommend to the
end-users as safe and practical to use.  That does tend to rule out major
out-of-tree patches, especially for kernel, and especially especially for
union filesystems, which have a multi-decade history of being created
out-of-tree and never becoming good enough to include in the mainline.

For developers, the current work of enabling copr and other related
activities should make the developers' life easier without impacting the
end users.

That said, I do think we should not be hostile to small Fedora-specific
patches that include the *integration* of the distribution.


What I hope will happen with the "Productization" of Fedora is that these
> products will be allowed to have a more independent identity and given more
> leeway to do things different. I will go so far and hope that eventually
> these products will be allowed to have their own policies regarding
> packaging and for example be able to ship their own kernel packages likely
> to be derived from the main kernel but with additional patches as the ones
> mentioned above.
>

So far FESCo has had a fairly strong consensus on minimizing the
differences within packages between Products--it's fine for the Products to
differ in package selection, but differences in package content, while
probably inevitable, should be minimized.


> Anyway my point is that telling product A that they cannot proceed with
> their work until product B is released is pretty much the opposite of what
> you want to do.
>

That's not the F21 situation: what has been considered is that no new
products (not targeted at any particular one) could proceed until we know
that the infrastructure for *all* projects is workable (with the current
three products serving as guinea pigs, thinking that we do need
*some*guinea pigs but having more is not useful).


> Instead the message should be: "Want to create a new way to manage the
> update life-cycle of systems (OSTree)? Want to create a new way to manage
> better application deployment (Docker)? Build a Fedora product as Fedora
> can provide you with a solid foundation for whatever you are trying to
> accomplish!"
>

Well, the Fedora Products do need t*o still be Fedora*.  We shouldn't end
up in the other extreme position of Fedora providing hosting to dozens of
software distribution projects that have nothing in common, and there is a
definite balance to be struck.  To me, a significant factor in the balance
is "does the subproject benefit from, and is it beneficial to, the work of
the thousands of Fedora contributors not working on that subproject?",
which would rule out single Products unilaterally moving away from RPM and
ignoring the bugfixing and patching done by Fedora contributors on the
RPMs, for example.
 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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Miloslav Trmač]

2014-03-21 10:02 GMT+01:00 Jaroslav Reznik :

> > KDE should not be a top level Product. In my opinion, Fedora should only
> > produce the currently listed 3 Products and not more. Otherwise we get
> > back at square 1 where we have too many offerings and nobody knows what
> > makes a supported Fedora.
> > Kubuntu is to Ubuntu now.
>
> I really can't agree with only three products doctrine forever.


Yeah, something like OLPC (not packaging of existing software, but actually
designing the OLPC OS) should be definitely be a Product in Fedora.next.
So far I'm unconvinced about KDE--but then I haven't seen the proposal :)


> Also this high bar leads to another question - exactly opposite to the
> escalation of spin to product. What if one of multiple products stops to
> fulfil these high bar standards?
>

When we say that there should be "high bar" for becoming a Fedora Product,
that means that there should be few of them, with resources commensurate
with the significant attention such products will receive.  I'm afraid it
doesn't imply "high bar" of quality--we have way too many small regressions
and unfixed bugs in the shipped product to claim that, and within a
volunteer organization, no practical way to change that.

Yes, the situation of having too few contributors or really bad quality of
a Product could happen--and in such a situation it would be perfectly
reasonable to drop that Product.  OTOH when I see how much some motivated
*individuals* can accomplish, we don't need *that* many to keep the
products presentable, and I'm not worried that the primary Products will be
*that* starved for manpower and attention any time soon.
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Miloslav Trmač]

2014-03-21 1:00 GMT+01:00 Lennart Poettering :

> On Thu, 20.03.14 13:44, Stephen John Smoogen (smo...@gmail.com) wrote:
> > And now I need to have X number applications special syntax to
> > whitelist/blacklist a site. I need to change X files to make that change.
> > Each of those could be a separate change control process depending on the
> > size of the organization. Or I have 1 file that I can make a change to
> > which has usually one syntax and one set of reviews.
>
> Well, if you filter in postfix or ssh, then you have a domain-specific,
> powerful language there. You can not only match on source addresses, but
> also on user names, groups, authentication methods, connection features
> SASL schemes, crypto algorithms, ... It's a very good thing being able
> to control this in a unified, but domain-specific way.


What's "unified" about that?

Also, most of the things you mention should be up to administrator's policy
decision ("what authentication method or crypto is accepted") but not
really subnet- or domain-specific.  As a heuristic, "If you can't build a
reasonable GUI for it, you can't explain it or validate it and it will be
misunderstood."  (... that heuristic would kill so much of our servers'
options :) )


> If you want that unified language that can actually cover all kinds of
> apps and traffic, then use a firewall. It is truly universal (unlike
> tcpwrappers), and at least as powerful...
>

Using firewall with RPC services is possible but essentially defeats the
point of portmap, which is to avoid using dynamically allocated IP port
numbers and to instead use protocol / RPC references.

DNS queries can't really be done within the firewall (and due to the
circular dependency between having the firewall up before allowing access
to the network and needing access to the network to resolve DNS names, they
can't even be used in the on-disk firewall configuration).  Having a single
centralized name->IP address repository instead of having a redundant copy
in each host, and having the configuration use readable names instead of IP
addresses, makes some difference in usability and management overhead.

Also, note that an organization *can* actually make DNS sufficiently secure
by using their own DNS servers that have authoritative sources for the
relevant domains, even without DNSSEC: this would keep out all script
kiddies and internet-originating attackers who can't attack the link
between the tcp_wrappers user and the DNS server, while still allowing
attacks from a compromised computer within the organization--which is
*exactly* the case where the domain-specific configuration would probably
allow access *anyway*, so the attacker might have nothing to gain by
subverting DNS.  (Yes, there are many possible configurations of
tcp_wrappers where this argument does not apply, and it does require care
from the administrators of the system.)


The RHEL documentation, apart from fully describing the abilities,
specifically describes two uses: a ftpd banner, and running arbitrary shell
to collect intrusion detection statistics.  Neither is reasonably easy to
do with the firewall.  Now I'm not saying that these specific features are
critical :)


We *do* need to *actually understand* the user's motivations for using
tcp_wrappers, not just dismiss it as security theater--because even if it
*were* security theater, if we don't know why the users are doing this they
are likely to do it in the new system as well, and we will end up with even
a bigger mess implementing the same security theater.
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 23:37, schrieb Jóhann B. Guðmundsson:
> 
> On 03/21/2014 10:35 PM, Reindl Harald wrote:
>> the author of tcpwrapper is Wietse Venema,
> 
> You do realize when he wrote this and what he was trying to overcome at that 
> time so I have to ask have you spoken
> to him about how useful he thinks his creation is today and why he stopped 
> maintaining it?
> 
> If not I suggest you do and hear what he thinks and says about it...

let hear

most things deprecated the past years are deprecated because they don't
receive a upstrea update every weak and people depcrate them doing
so because they can't imagine that things just work

if you believe it or not: there exists code which don't neeed
updates and reweites all te time because it just works and given
the amount of bugs in systemd Fedora 20/Rawhide, well, better
there would have been no improvement after Fedora 19

does this care upstream: no it does not

but hey, propose other peoples code to be deprecatd is so much easier



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Jóhann B. Guðmundsson]

On 03/21/2014 10:35 PM, Reindl Harald wrote:

the author of tcpwrapper is Wietse Venema,


You do realize when he wrote this and what he was trying to overcome at 
that time so I have to ask have you spoken to him about how useful he 
thinks his creation is today and why he stopped maintaining it?


If not I suggest you do and hear what he thinks and says about it...

JBG
--
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-Net-Twitter-Lite/el6] Initial import (#1074482).

[David Dick]

Summary of changes:

  3f04fa4... Initial import (#1074482). (*)

(*) This commit already existed in another branch; no separate mail sent
--
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 23:31, schrieb Jóhann B. Guðmundsson:
> 
> On 03/21/2014 10:30 PM, Martin Langhoff wrote:
>> On Fri, Mar 21, 2014 at 6:16 PM, "Jóhann B. Guðmundsson" > > wrote:
>>
>> In other words you are telling us that now to get something implemented 
>> or removed in Fedora we have to not
>> only deal with our usual politics and bureaucracy but also all the 
>> downstream distribution to us as well...
>>
>>
>> One way to avoid those pesky details is to not have users... :-)
> 
> One way to prevent advancement and innovation within Fedora is precisely 
> what's taking place here.
> 
> Three layers to get things done... 

you call it "innovation"

others call it bad names to break every day compatibility and force
anybody to follow changes nobobody asked for because only if changes
have a great impact to anybody they are recognized

the whole environment moves in circles with less to zero gain
the last past years but hey you are cool if you change things



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 23:16, schrieb Jóhann B. Guðmundsson:
> On 03/21/2014 02:05 PM, Matthew Miller wrote:
>> On Thu, Mar 20, 2014 at 06:34:22PM +0100, Lennart Poettering wrote:
>>> >I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
>>> >Fedora. There has been a request in systemd upstream to disable support
>> I talked to some of the RHEL planning people, and they're okay
>> with marking it deprecated in RHEL7. That allays some of my concerns about
>> downstream enterprise needs -- although there was also the comment that the
>> libwrap2 approach would be a good one.
>>
>> I'm also collecting some feedback from CentOS users. I'll wait to report on
>> that for a little bit, but I think in general the majority response is okay
>> with it, with a significantly vocal "why change things that work?"
> 
> In other words you are telling us that now to get something implemented or 
> removed in Fedora we have to not only
> deal with our usual politics and bureaucracy but also all the downstream 
> distribution to us as well...

no, in other words he told you that whe world is not turning around
a few people deperecating anything which does not get a update for
the sake of a update and what some people calling  "legacy" might
be things not needing updates because they just works and update
and replace/drop for the sake of a change does not make things
better for no good reason

the author of tcpwrapper is Wietse Venema, the perosn who created
and maintains postfix - frankly if only 1% of the software out
there would provide his stability and backwards compatibility
a lot of peole could do better things with their time than creat
day for day in case of deprecations and incompatible replacemnets

most of the replacements in the last few years could have been
becakward compatible if the developers would not be too lazy
to care 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

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Jóhann B. Guðmundsson]

On 03/21/2014 10:30 PM, Martin Langhoff wrote:
On Fri, Mar 21, 2014 at 6:16 PM, "Jóhann B. Guðmundsson" 
mailto:johan...@gmail.com>> wrote:


In other words you are telling us that now to get something
implemented or removed in Fedora we have to not only deal with our
usual politics and bureaucracy but also all the downstream
distribution to us as well...


One way to avoid those pesky details is to not have users... :-)


One way to prevent advancement and innovation within Fedora is precisely 
what's taking place here.


Three layers to get things done...

JBG
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Martin Langhoff]

On Fri, Mar 21, 2014 at 6:16 PM, "Jóhann B. Guðmundsson"  wrote:

> In other words you are telling us that now to get something implemented or
> removed in Fedora we have to not only deal with our usual politics and
> bureaucracy but also all the downstream distribution to us as well...


One way to avoid those pesky details is to not have users... :-)


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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Jóhann B. Guðmundsson]

On 03/21/2014 02:05 PM, Matthew Miller wrote:

On Thu, Mar 20, 2014 at 06:34:22PM +0100, Lennart Poettering wrote:

>I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
>Fedora. There has been a request in systemd upstream to disable support

I talked to some of the RHEL planning people, and they're okay
with marking it deprecated in RHEL7. That allays some of my concerns about
downstream enterprise needs -- although there was also the comment that the
libwrap2 approach would be a good one.

I'm also collecting some feedback from CentOS users. I'll wait to report on
that for a little bit, but I think in general the majority response is okay
with it, with a significantly vocal "why change things that work?"


In other words you are telling us that now to get something implemented 
or removed in Fedora we have to not only deal with our usual politics 
and bureaucracy but also all the downstream distribution to us as well...


JBG
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

PEP453 // ensurepip // pip

[Donald Stufft]

Hey there,

So I’m one of the authors of PEP453, the original implementor of ensurepip, and
a pip maintainer. I know that pip (and other language level package managers)
have a sort of love/hate (sometimes more of one or the other!) relationship
with the downstream Linux packagers. I know that PEP453 also puts more focus
on this in general since it's now a recommendation for pip to be installed
if Python is.

So I'd like to say that If there are problems I'd like to help fix them.
Especially if there are problems with pip that make you nervous/upset/sad with
having it tied so closely to Python. Also generally about making less headache
for distros where pip is involved (pip and the OS package manager stomping on
each other etc).

To start off this goal I've filed https://github.com/pypa/pip/issues/1668 to
figure out how pip can get our defaults to the point where most users will be
installing to ~/.local/ instead of the system location. If there's more things
pip can do I'd love to know about them, or if ensurepip or the PEP453 processes
have something I can help with too :)

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
python-devel mailing list
python-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/python-devel

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Reindl Harald]

Am 21.03.2014 20:02, schrieb Florian Weimer:
> * Lennart Poettering:
> 
>>> So offer something with equivalent functionality (and config file
>>> syntax compatibility), with a nice modern clean API and then systemd
>>> and others can be moved over to that 1 by 1, and once we've no more
>>> users left we can kill of the old beast ?
>>
>> Nope. In systemd we already support one subsystem for filtering just
>> fine, it's called a firewall.
> 
> Does this subsystem support DNS-based rules?

and even if it does you do *not* want dns-resolution based
on packets instead connections - guess how many users would
make the mistake resulting in a selfDOS



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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Florian Weimer]

* Lennart Poettering:

>> So offer something with equivalent functionality (and config file
>> syntax compatibility), with a nice modern clean API and then systemd
>> and others can be moved over to that 1 by 1, and once we've no more
>> users left we can kill of the old beast ?
>
> Nope. In systemd we already support one subsystem for filtering just
> fine, it's called a firewall.

Does this subsystem support DNS-based rules?
-- 
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: Packaging changes on NetworkManager? Whither NetworkManager-glib...

[Dan Mashal]

On Fri, Mar 21, 2014 at 9:04 AM, Philip Prindeville
 wrote:
> Did something recently change with the packaging of NetworkManager?
>
> I'm not finding NetworkManager-glib, just NetworkManager-glib-devel:
>
> [root@builder philipp]# yum update
> Loaded plugins: langpacks, refresh-packagekit
> adobe-linux-x86_64   |  951 B 00:00
> rpmfusion-free-updates   | 3.3 kB 00:00
> updates/20/x86_64/metalink   | 9.7 kB 00:00
> updates  | 4.6 kB 00:00
> Resolving Dependencies
> --> Running transaction check
> ---> Package libnm-gtk.x86_64 0:0.9.9.0-7.git20131028.fc20 will be updated
> ---> Package libnm-gtk.x86_64 0:0.9.9.0-8.git20140123.fc20 will be an update
> ---> Package nm-connection-editor.x86_64 0:0.9.9.0-7.git20131028.fc20 will be 
> updated
> ---> Package nm-connection-editor.x86_64 0:0.9.9.0-8.git20140123.fc20 will be 
> an update
> --> Processing Dependency: NetworkManager-glib >= 1:0.9.9.0-26 for package: 
> nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64
> --> Finished Dependency Resolution
> Error: Package: nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64 
> (updates)
>Requires: NetworkManager-glib >= 1:0.9.9.0-26
>Installed: 
> 1:NetworkManager-glib-0.9.9.0-20.git20131003.fc20.x86_64 (@fedora)
>NetworkManager-glib = 1:0.9.9.0-20.git20131003.fc20
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> [root@builder philipp]# repoquery NetworkManager\*
> NetworkManager-config-server-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.i686
> NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.i686
> NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-iodine-0:0.0.4-2.fc20.x86_64
> NetworkManager-iodine-gnome-0:0.0.4-2.fc20.x86_64
> NetworkManager-l2tp-0:0.9.8.6-1.fc20.x86_64
> NetworkManager-openconnect-0:0.9.8.0-2.fc20.x86_64
> NetworkManager-openswan-0:0.9.8.0-1.fc20.x86_64
> NetworkManager-openvpn-1:0.9.9.0-0.1.git20140128.fc20.x86_64
> NetworkManager-openvpn-gnome-1:0.9.9.0-0.1.git20140128.fc20.x86_64
> NetworkManager-pptp-1:0.9.8.2-3.fc20.x86_64
> NetworkManager-pptp-gnome-1:0.9.8.2-3.fc20.x86_64
> NetworkManager-ssh-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
> NetworkManager-ssh-gnome-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
> NetworkManager-vpnc-1:0.9.8.2-2.fc20.x86_64
> NetworkManager-vpnc-gnome-1:0.9.8.2-2.fc20.x86_64
> [root@builder philipp]#

Don't see anything changed.

It's in the repos...

$ yum search NetworkManager-glib
Loaded plugins: fastestmirror, langpacks, refresh-packagekit
Loading mirror speeds from cached hostfile
 * fedora: mirrors.kernel.org
 * rpmfusion-free: mirror.web-ster.com
 * rpmfusion-free-updates: mirror.web-ster.com
 * rpmfusion-free-updates-testing: mirror.web-ster.com
 * rpmfusion-nonfree: mirror.web-ster.com
 * rpmfusion-nonfree-updates: mirror.web-ster.com
 * rpmfusion-nonfree-updates-testing: mirror.web-ster.com
 * updates: mirrors.kernel.org
updates/20/x86_64/pkgtags| 1.0 MB 00:00
=== N/S matched: NetworkManager-glib ===
NetworkManager-glib.i686 : Libraries for adding NetworkManager support to
 : applications that use glib.
NetworkManager-glib.x86_64 : Libraries for adding NetworkManager support to
   : applications that use glib.
NetworkManager-glib-devel.i686 : Header files for adding NetworkManager support
   : to applications that use glib.
NetworkManager-glib-devel.x86_64 : Header files for adding NetworkManager
 : support to applications that use glib.

  Name and summary matches only, use "search all" for everything.

You could always download the rpm from koji.


Dan
-- 
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: Packaging changes on NetworkManager? Whither NetworkManager-glib...

[Dan Williams]

On Fri, 2014-03-21 at 10:04 -0600, Philip Prindeville wrote:
> Did something recently change with the packaging of NetworkManager?
> 
> I’m not finding NetworkManager-glib, just NetworkManager-glib-devel:

Outdated mirrors perhaps?  It's clearly in the repos:

http://mirror.cc.vt.edu/pub/fedora/linux//updates/20/x86_64/NetworkManager-glib-0.9.9.0-32.git20131003.fc20.x86_64.rpm

Does "yum clean all; yum upgrade" make things better?

Dan

> [root@builder philipp]# yum update 
> Loaded plugins: langpacks, refresh-packagekit
> adobe-linux-x86_64   |  951 B 00:00   
>   
> rpmfusion-free-updates   | 3.3 kB 00:00   
>   
> updates/20/x86_64/metalink   | 9.7 kB 00:00   
>   
> updates  | 4.6 kB 00:00   
>   
> Resolving Dependencies
> --> Running transaction check
> ---> Package libnm-gtk.x86_64 0:0.9.9.0-7.git20131028.fc20 will be updated
> ---> Package libnm-gtk.x86_64 0:0.9.9.0-8.git20140123.fc20 will be an update
> ---> Package nm-connection-editor.x86_64 0:0.9.9.0-7.git20131028.fc20 will be 
> updated
> ---> Package nm-connection-editor.x86_64 0:0.9.9.0-8.git20140123.fc20 will be 
> an update
> --> Processing Dependency: NetworkManager-glib >= 1:0.9.9.0-26 for package: 
> nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64
> --> Finished Dependency Resolution
> Error: Package: nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64 
> (updates)
>Requires: NetworkManager-glib >= 1:0.9.9.0-26
>Installed: 
> 1:NetworkManager-glib-0.9.9.0-20.git20131003.fc20.x86_64 (@fedora)
>NetworkManager-glib = 1:0.9.9.0-20.git20131003.fc20
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> [root@builder philipp]# repoquery NetworkManager\*
> NetworkManager-config-server-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.i686
> NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.i686
> NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
> NetworkManager-iodine-0:0.0.4-2.fc20.x86_64
> NetworkManager-iodine-gnome-0:0.0.4-2.fc20.x86_64
> NetworkManager-l2tp-0:0.9.8.6-1.fc20.x86_64
> NetworkManager-openconnect-0:0.9.8.0-2.fc20.x86_64
> NetworkManager-openswan-0:0.9.8.0-1.fc20.x86_64
> NetworkManager-openvpn-1:0.9.9.0-0.1.git20140128.fc20.x86_64
> NetworkManager-openvpn-gnome-1:0.9.9.0-0.1.git20140128.fc20.x86_64
> NetworkManager-pptp-1:0.9.8.2-3.fc20.x86_64
> NetworkManager-pptp-gnome-1:0.9.8.2-3.fc20.x86_64
> NetworkManager-ssh-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
> NetworkManager-ssh-gnome-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
> NetworkManager-vpnc-1:0.9.8.2-2.fc20.x86_64
> NetworkManager-vpnc-gnome-1:0.9.8.2-2.fc20.x86_64
> [root@builder philipp]# 
> 
> 
> For what it’s worth, I don’t even use NetworkManager as my desktop machine 
> has no Wifi, no VPN tunnels, etc.  So I just use the ‘network’ service 
> instead.  It would be nice if control-center didn’t have a dependency on 
> NetworkManager, and that it was optional instead.
> 
> -Philip
> 


-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Fri, 21.03.14 13:05, Paul Wouters (p...@nohats.ca) wrote:

> On Fri, 21 Mar 2014, Lennart Poettering wrote:
> 
> >As long as -lresolve (i.e. glibc and getaddrinfo()) can't do DNSSEC it's
> >just not there...
> 
> You are proposing changing the api of getaddrinfo()? Could luck with
> that?

Dunno, it doesn't sound too difficult to add a new flag .ai_flags that
indicates whether the dns data has been verified locally or so... 

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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Paul Wouters]

On Fri, 21 Mar 2014, Lennart Poettering wrote:


As long as -lresolve (i.e. glibc and getaddrinfo()) can't do DNSSEC it's
just not there...


You are proposing changing the api of getaddrinfo()? Could luck with
that?

Yes, applications that want to see DNSSEC results will have to do a little bit
of extra work. It's not the end of the world. Applications that only
care about the DNS being protected should just continue their current
API, and hopefully resolv.conf points to localhost so the local DNS
server will return ServFail's to the applications for spoofed DNS.


Some progress is being made elsewhere to come up with an API that's
somewhere in the middle between blind AD bit trust and running a
full dnssec cache in the application, eg getdns api:

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


Ah, yet another DNS API... Because we have so few... A library with an
API of getdns_list_create_with_extended_memory_functions() looks really
promising... not!


It's built on top of libunbound. You can use libunbound directly.

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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Fri, 21.03.14 12:37, Paul Wouters (p...@nohats.ca) wrote:

> On Fri, 21 Mar 2014, Lennart Poettering wrote:
> 
> >>we kinda do have dnssec per default. All DNS servers installed per
> >>default do DNSSEC. Installing dnssec-trigger makes that even more
> >>pervasive.
> >
> >Well, but glibc can't do the DNSSEC client side, can it?
> 
> Applications that want to do DNSSEC validation can use one of the
> dns libraries available (libunbound, libisc, ldns, libval) or their
> python/perl bindings. Or they can trust the system and depend on the AD
> bit from a locally running nameserver.

Well, but tcpd doesn't use that.

As long as -lresolve (i.e. glibc and getaddrinfo()) can't do DNSSEC it's
just not there...

> Some progress is being made elsewhere to come up with an API that's
> somewhere in the middle between blind AD bit trust and running a
> full dnssec cache in the application, eg getdns api:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1070510

Ah, yet another DNS API... Because we have so few... A library with an
API of getdns_list_create_with_extended_memory_functions() looks really
promising... not!

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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Paul Wouters]

On Fri, 21 Mar 2014, Lennart Poettering wrote:


we kinda do have dnssec per default. All DNS servers installed per
default do DNSSEC. Installing dnssec-trigger makes that even more
pervasive.


Well, but glibc can't do the DNSSEC client side, can it?


Applications that want to do DNSSEC validation can use one of the
dns libraries available (libunbound, libisc, ldns, libval) or their
python/perl bindings. Or they can trust the system and depend on the AD
bit from a locally running nameserver.

Some progress is being made elsewhere to come up with an API that's
somewhere in the middle between blind AD bit trust and running a
full dnssec cache in the application, eg getdns api:

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

In addition to making it easier to get all the records in one go to do
validation and then throw away the intermediate data:

https://tools.ietf.org/html/draft-wouters-edns-chain-query-00

There is still a larger discussion going on about how exactly to fit
DNSSEC in the OS and applications. Some people don't like blind trust,
some people don't tying the application too tightly to DNSSEC. But
with TLSA records in DNS, there is now a need to add DNSSEC to crypto
libraries.

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

[Base] Fedora Base Design Working Group (2014-03-14) meeting minutes and logs

[Phil Knirsch]

Hi all.

Agenda for today was discussing the tech spec that masta wanted to 
write. Unfortunately due to his other workload he wasn't able to 
complete it by today, so we postponed the discussion to next week.


In the openfloor session we brought up a topic from jreznik about any 
requirements Base might have for docs, but we didn't find anything new, 
just the "old" installer and other core items. Once the tech spec is 
done we'll double check if anything new came up and if so contact docs 
of course.


Next weeks meeting will be held by masta as i'm on PTO the whole next week.

Thats all!

Thanks & regards, Phil

Meeting ended Fri Mar 21 15:34:08 2014 UTC. Information about MeetBot at 
http://wiki.debian.org/MeetBot .
Minutes: 
http://meetbot.fedoraproject.org/fedora-meeting/2014-03-21/fedora_base_design_working_group.2014-03-21-15.00.html
Minutes (text): 
http://meetbot.fedoraproject.org/fedora-meeting/2014-03-21/fedora_base_design_working_group.2014-03-21-15.00.txt
Log: 
http://meetbot.fedoraproject.org/fedora-meeting/2014-03-21/fedora_base_design_working_group.2014-03-21-15.00.log.html


--
Philipp Knirsch  | Tel.:  +49-711-96437-470
Manager Core Services| Fax.:  +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch 
Wankelstrasse 5  | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Packaging changes on NetworkManager? Whither NetworkManager-glib...

[Philip Prindeville]

Did something recently change with the packaging of NetworkManager?

I’m not finding NetworkManager-glib, just NetworkManager-glib-devel:

[root@builder philipp]# yum update 
Loaded plugins: langpacks, refresh-packagekit
adobe-linux-x86_64   |  951 B 00:00 
rpmfusion-free-updates   | 3.3 kB 00:00 
updates/20/x86_64/metalink   | 9.7 kB 00:00 
updates  | 4.6 kB 00:00 
Resolving Dependencies
--> Running transaction check
---> Package libnm-gtk.x86_64 0:0.9.9.0-7.git20131028.fc20 will be updated
---> Package libnm-gtk.x86_64 0:0.9.9.0-8.git20140123.fc20 will be an update
---> Package nm-connection-editor.x86_64 0:0.9.9.0-7.git20131028.fc20 will be 
updated
---> Package nm-connection-editor.x86_64 0:0.9.9.0-8.git20140123.fc20 will be 
an update
--> Processing Dependency: NetworkManager-glib >= 1:0.9.9.0-26 for package: 
nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64
--> Finished Dependency Resolution
Error: Package: nm-connection-editor-0.9.9.0-8.git20140123.fc20.x86_64 (updates)
   Requires: NetworkManager-glib >= 1:0.9.9.0-26
   Installed: 1:NetworkManager-glib-0.9.9.0-20.git20131003.fc20.x86_64 
(@fedora)
   NetworkManager-glib = 1:0.9.9.0-20.git20131003.fc20
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
[root@builder philipp]# repoquery NetworkManager\*
NetworkManager-config-server-1:0.9.9.0-31.git20131003.fc20.x86_64
NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.i686
NetworkManager-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.i686
NetworkManager-glib-devel-1:0.9.9.0-31.git20131003.fc20.x86_64
NetworkManager-iodine-0:0.0.4-2.fc20.x86_64
NetworkManager-iodine-gnome-0:0.0.4-2.fc20.x86_64
NetworkManager-l2tp-0:0.9.8.6-1.fc20.x86_64
NetworkManager-openconnect-0:0.9.8.0-2.fc20.x86_64
NetworkManager-openswan-0:0.9.8.0-1.fc20.x86_64
NetworkManager-openvpn-1:0.9.9.0-0.1.git20140128.fc20.x86_64
NetworkManager-openvpn-gnome-1:0.9.9.0-0.1.git20140128.fc20.x86_64
NetworkManager-pptp-1:0.9.8.2-3.fc20.x86_64
NetworkManager-pptp-gnome-1:0.9.8.2-3.fc20.x86_64
NetworkManager-ssh-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
NetworkManager-ssh-gnome-0:0.9.2-0.2.20140209git46247c2.fc20.x86_64
NetworkManager-vpnc-1:0.9.8.2-2.fc20.x86_64
NetworkManager-vpnc-gnome-1:0.9.8.2-2.fc20.x86_64
[root@builder philipp]# 


For what it’s worth, I don’t even use NetworkManager as my desktop machine has 
no Wifi, no VPN tunnels, etc.  So I just use the ‘network’ service instead.  It 
would be nice if control-center didn’t have a dependency on NetworkManager, and 
that it was optional instead.

-Philip

-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Dominick Grift]

On Thu, 2014-03-20 at 20:55 +0100, Hans de Goede wrote:

> So offer something with equivalent functionality (and config file
> syntax compatibility), with a nice modern clean API and then systemd
> and others can be moved over to that 1 by 1, and once we've no more
> users left we can kill of the old beast ?

+1
I use tcp-wrappers, if only for fail-over. Layered defense i suppose.


-- 
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: Java 8

[Dan Horák]

On Fri, 21 Mar 2014 10:24:05 -0400 (EDT)
Omair Majid  wrote:

> 
> 
> - Original Message -
> From: "Dan Horák" 
> > Jaroslav Reznik  wrote:
> > > Make Java 8 (provided by OpenJDK 8 which is java-1.8.0-openjdk)
> > > the default Java runtime. The current default Java runtime (Java
> > > 7, provided by OpenJDK 7, java-1.7.0-openjdk) will be obsoleted
> > > and removed.
> 
> > are we confident OpenJDK 8 works well on all Fedora arches, not
> > only on the primary ones?
> 
> Theoretically, yes. If OpenJDK 7 supports an architecture, OpenJDK 8
> should support it about as well (if not better). We may need tweaks
> and patches to make sure OpenJDK 8 builds correctly everywhere, but
> that's one of the things we can fix in rawhide in the coming weeks.
> 
> If you can get me access to machines, I can try building OpenJDK 8
> there myself.

thanks, I'll reach you internally with the logon details, we had the
problem on 32-bit s390 only which means working in a chroot, so I'll
retry first


Dan
-- 
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: Java 8

[Omair Majid]

- Original Message -
From: "Dan Horák" 
> Jaroslav Reznik  wrote:
> > Make Java 8 (provided by OpenJDK 8 which is java-1.8.0-openjdk) the
> > default Java runtime. The current default Java runtime (Java 7,
> > provided by OpenJDK 7, java-1.7.0-openjdk) will be obsoleted and
> > removed.

> are we confident OpenJDK 8 works well on all Fedora arches, not only on
> the primary ones?

Theoretically, yes. If OpenJDK 7 supports an architecture, OpenJDK 8 should 
support it about as well (if not better). We may need tweaks and patches to 
make sure OpenJDK 8 builds correctly everywhere, but that's one of the things 
we can fix in rawhide in the coming weeks.

If you can get me access to machines, I can try building OpenJDK 8 there myself.

Thanks,
Omair

-- 
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: Java 8

[Omair Majid]

- Original Message -
> Is there an easy way to do test builds against 8 now?

java-1.8.0-openjdk is available in F19 (updates-testing), F20 (updates-testing) 
and in rawhide.

It doesn't provide 'java-devel' (which is what yum uses to find JDKs), so Koji 
shouldn't use java-1.8.0-openjdk as a dependency. But you can use 
java-1.8.0-openjdk-devel directly for local or scratch builds.

Thanks,
Omair
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Base] Base Design WG agenda meeting 21. Mar 2014 15:00 UTC on #fedora-meeting

[Phil Knirsch]

Agenda:
 - Discuss draft for Tech Spec for Base Design
 - Open Floor

Thanks & regards, Phil

--
Philipp Knirsch  | Tel.:  +49-711-96437-470
Manager Core Services| Fax.:  +49-711-96437-111
Red Hat GmbH | Email: Phil Knirsch 
Wankelstrasse 5  | Web:   http://www.redhat.com/
D-70563 Stuttgart, Germany
--
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-Test-Modern/f20] Initial import (perl-Test-Modern-0.002-3)

[Paul Howarth]

Summary of changes:

  1567260... Initial import (perl-Test-Modern-0.002-3) (*)

(*) This commit already existed in another branch; no separate mail sent
--
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Matthew Miller]

On Thu, Mar 20, 2014 at 06:34:22PM +0100, Lennart Poettering wrote:
> I wonder whether it wouldn't be time to say goodbye to tcpwrappers in
> Fedora. There has been a request in systemd upstream to disable support

I talked to some of the RHEL planning people, and they're okay
with marking it deprecated in RHEL7. That allays some of my concerns about
downstream enterprise needs -- although there was also the comment that the
libwrap2 approach would be a good one.

I'm also collecting some feedback from CentOS users. I'll wait to report on
that for a little bit, but I think in general the majority response is okay
with it, with a significantly vocal "why change things that work?"
contingent, and also the more practical concerns that a) tcp_wrappers is
cross-platform for mixed Linux/Unix shops where iptables is not, and b) CIS
(Center for Internet Security) benchmarks (taken seriously in many
enterprises) recommend both TCP wrappers and host-based packet filtering,
noting "TCP Wrappers and Host-Based Firewalls are presented together as they
are similar and complementary in functionality."

Those two concerns do give me some pause; it might be nice to at least
discuss with CIS whether the benchmark should be updated. And the
cross-compatibility concern argues for either the libwrap2 idea or the
compatible firewall-rule-generator concept.

-- 
Matthew Miller--   Fedora Project--
-- 
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: Java 8

[Bruno Wolff III]

On Fri, Mar 21, 2014 at 13:11:44 +0100,
  Jaroslav Reznik  wrote:

= Proposed System Wide Change: Java 8 =
https://fedoraproject.org/wiki/Changes/Java8

It may be a good idea to mass rebuild Java packages against OpenJDK 8 to spot
any source incompatibilities earlier. This is not required.


Is there an easy way to do test builds against 8 now?
--
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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Dennis Jacobfeuerborn]

On 21.03.2014 13:24, Christian Schaller wrote:

- Original Message -

From: "Matthew Miller" 
To: "Development discussions related to Fedora" 
Sent: Friday, March 21, 2014 12:59:01 PM
Subject: Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

On Fri, Mar 21, 2014 at 10:28:26AM +0100, Marcela Mašláňová wrote:

I agree with Jaroslav. I was looking forward to have a fourth
product to those three. KDE can help define what is needed for new
product, what must be done by all teams, how much work it will be
... I guess we should speak more about addition of new product and
don't kill the idea at the start.


Like I said, I'm skeptical, but listening. :)



While opinions differ on if we should 'ever' have more than 3 products, 
personally am very skeptical
to the idea of product proliferation, I think that as a minimum common sense 
measure we should not even consider
any further products before we have the current 3 products released and our 
infrastructure updated to handle
them.


I think this way of thinking about products is fundamentally wrong 
headed as that means that products are not independent from each other.


As I perceive it one of the biggest problems for Fedora as a development 
platform for new technologies is that everything is tied to very 
rigorous guidelines and controls that tend to be fairly conservative. 
This is great when you care about overall stability and coherence of the 
platform but terrible if you want to enable people to use Fedora as a 
platform to spearhead new technologies.


One example is the policy that patches for packages should first be 
submitted and accepted upstream before they make it into Fedora. This 
works great because that way you can ensure that once features are added 
in Fedora it is unlikely that they have to be removed later again 
because they are rejected upstream. It's terrible though if you want to 
live on the bleeding edge. Take for example the networking features of 
OpenStack that required kernel changes that weren't yet committed 
upstream or the fact that Docker required AUFS for a long time. In both 
cases Fedora was a terrible platform to develop these technologies 
because of its conservative stance.


What I hope will happen with the "Productization" of Fedora is that 
these products will be allowed to have a more independent identity and 
given more leeway to do things different. I will go so far and hope that 
eventually these products will be allowed to have their own policies 
regarding packaging and for example be able to ship their own kernel 
packages likely to be derived from the main kernel but with additional 
patches as the ones mentioned above.


This could be accomplished by making Copr an official Repository that 
products are allowed to rely on and which could be used to host 
alternative versions of packages. A product XYZ could have a channel XYZ 
in Copr and packages that are placed there are preferred over packages 
with the same name in the traditional repos.


Anyway my point is that telling product A that they cannot proceed with 
their work until product B is released is pretty much the opposite of 
what you want to do.


Instead the message should be: "Want to create a new way to manage the 
update life-cycle of systems (OSTree)? Want to create a new way to 
manage better application deployment (Docker)? Build a Fedora product as 
Fedora can provide you with a solid foundation for whatever you are 
trying to accomplish!"


Regards,
  Dennis
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Updated Rawhide to nss-3.16

[Elio Maldonado Batiz]

nss 3.16 was released this week and is now on Rawhide. Details in the 
upstream release notes at

https://developer.mozilla.org/en-US/docs/NSS/NSS_3.16_release_notes.
It should appear on updated testing for fedora stable branches next week.

Elio



--
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: DSO API stability guidelines

[Neil Horman]

On Fri, Mar 21, 2014 at 01:25:52PM +0100, Michal Schmidt wrote:
> On 03/21/2014 01:18 PM, Neil Horman wrote:
> > Can anyone point me to fedora packaging documentation that discusses
> > the need for API stability in packaged shared libraries?  I'm sure we
> > have some requirement that APIs in a DSO need to be versioned and
> > maintained through a release, but for the life of me I'm unable to
> > find it.
> 
> Hi Neil,
> 
> The Updates Policy for stable releases
> (http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases)
> says this about ABIs, APIs:
>   ABI changes in general are very strongly discouraged, they force
>   larger update sets on users and they make life difficult for
>   third-party packagers.
>   [...]
>   Package maintainers MUST:
> Avoid Major version updates, ABI breakage or API changes if
> at all possible. 
> 
> Michal

Thanks Michal!
Neil

-- 
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: Java 8

[Dan Horák]

On Fri, 21 Mar 2014 13:11:44 +0100
Jaroslav Reznik  wrote:

> = Proposed System Wide Change: Java 8 =
> https://fedoraproject.org/wiki/Changes/Java8
> 
> Change owner(s): Omair Majid 
> 
> Make Java 8 (provided by OpenJDK 8 which is java-1.8.0-openjdk) the
> default Java runtime. The current default Java runtime (Java 7,
> provided by OpenJDK 7, java-1.7.0-openjdk) will be obsoleted and
> removed.

are we confident OpenJDK 8 works well on all Fedora arches, not only on
the primary ones? Task for myself (or any volunteer) is to check
whether https://bugzilla.redhat.com/show_bug.cgi?id=958232 is still open


Dan

> This is essentially an upgrade to the latest Java and OpenJDK
> version. 
> 
> == Detailed Description ==
> The current default Java 7 runtime in Fedora is OpenJDK 7. The latest
> version of OpenJDK, 8, was released on 18 March 2014. Given that
> Fedora 21 will not be released before August, it makes sense to
> include the latest version of OpenJDK in Fedora 21.
> 
> OpenJDK 8 is a significant update to Java. It brings in significant
> new features to the Java language, including lambdas, a new
> javascript engine and lots of new library features. A complete list
> of features is available [1].
> 
> OpenJDK 8 is a backwards compatible update. Theoretically everything
> that worked against OpenJDK 7 should continue working against OpenJDK
> 8. There are a few exceptions:
> 
> OpenJDK8 is much more strict when it comes to building javadocs.
> Many - javadoc package in Fedora fail to build. Those that are built
> should continue working just fine.
> Packages that rely on non-public OpenJDK API may fail to
> build/run. 
> 
> A complete list of incompatibilities is available [2]. The
> incompatibilities are source and behavioral only.
> 
> It may be a good idea to mass rebuild Java packages against OpenJDK 8
> to spot any source incompatibilities earlier. This is not required.  
> 
> == Scope ==
> * Proposal owners:
> ** Deprecate/Obsolete java-1.7.0-openjdk
> ** Promote java-1.8.0-openjdk to a full java runtime status (fix
> provides in package)
> ** In case of a mass rebuild, supply/apply patches to fix build
> against OpenJDK 8
> 
> * Other developers:
> ** icedtea-web maintainers will need to update icedtea-web to run
> against OpenJDK 8
> ** Other java packagers will need to apply patches to their java
> package to ensure they can build against OpenJDK 8
> ** Everyone will need to test packages to verify that they work
> against OpenJDK 8
> 
> * Release engineering:
> ** Remove java-1.7.0-openjdk
> ** Possibly mass-rebuild (?) all Java packages. This is not strictly
> required to make OpenJDK 8 the default Java runtime.
> 
> * Policies and guidelines: 
> ** Many -javadoc packages fail to build. The OpenJDK 8 maintainers
> and the Java SIG are working on identifying a solution. The solution
> may require [3] guideline changes making -javadoc subpackages
> optional.
> 
> [1] http://openjdk.java.net/projects/jdk8/features 
> [2]
> http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
> [3]
> https://lists.fedoraproject.org/pipermail/devel/2014-March/196808.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
-- 
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: NFS Ganesha File Server

[Jaroslav Reznik]

= Proposed Self Contained Change: NFS Ganesha File Server =
https://fedoraproject.org/wiki/Changes/NFSGanesha

Change owner(s): Jim Lieb 

NFS Ganesha is a user mode file server that supports NFSv3, NFSv4, and NFSv4.1 
including pNFS for distributed filesystems. It uses loadable filesystem driver 
modules to support its backend filesystems. It also integrates 9P.2000L file 
service. 

== Detailed Description ==
NFS Ganesha is a user-mode file server for NFS (v3, v4.0 , v4.1 pNFS) and for 
9P from the Plan9 UNIX O/S. It integrates with backend filesystems via its File 
System Abstraction Layer (FSAL) which is a set of loadable modules that 
implement the access to these filesystems. Using a FSAL is similar to FUSE in 
that the whole filesystem can be implemented in user space. This is especially 
advantagious for pNFS and distributed filesystems where storage is distributed 
across a network. For backend (FSAL) modules than can be supported , see 
Change Page.

Those FSALs labeled as Yes are packaged for Fedora. Those labeled Not Yet 
require upstream packages that are not available yet. Those labeled No cannot 
be packaged with Fedore either due to licensing or availability.

NFS Ganesha supports pNFS as both a metadata server (MDS) and a data server 
(DS). It supports both files and object layouts for depending on what is 
supported by the underlying filesystem. 

== Scope ==
This is a new package based on the new V2.0.0 upstream release. No other 
changes to the system are required.

* Proposal owners: The upstream just released (DEC 2013) V2.0.0. Initial 
packaging is complete and accepted. The package will be updated during the 
development period to the latest stable release.
* 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) 


___
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

Re: Maybe it's time to get rid of tcpwrappers/tcpd?

[Lennart Poettering]

On Fri, 21.03.14 00:27, Paul Wouters (p...@nohats.ca) wrote:

> On Fri, 21 Mar 2014, Lennart Poettering wrote:
> 
> >I mean, in this day and age we should not consider an ACL language well
> >designed if it basically pushes users to use IDENT and DNS for
> >authentication. (And no, don't say the words DNSSEC, nobody sets that
> >up, we don't have it as default, and tcpwrap doesn't check wether DNSSEC
> >is enabled either, before trusting a hostname...).
> 
> we kinda do have dnssec per default. All DNS servers installed per
> default do DNSSEC. Installing dnssec-trigger makes that even more
> pervasive.

Well, but glibc can't do the DNSSEC client side, can it?

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

F21 Self Contained Change: Apache Spark

[Jaroslav Reznik]

= Proposed Self Contained Change: Apache Spark =
https://fedoraproject.org/wiki/Changes/ApacheSpark

Change owner(s): William Benton 

Apache Spark is a fast and general engine for large-scale data processing. 
This change brings Spark to Fedora, allowing easy deployment and development 
of Spark applications on Fedora. 

== Detailed Description ==
Apache Spark is a fast and general engine for large-scale data processing. It 
supports developing custom analytic processing applications over large data 
sets or streaming data. Because it has the capability to cache intermediate 
results in cluster memory and schedule DAGs of computations, Spark programs 
can run up to 100x faster than equivalent Hadoop MapReduce jobs. Spark 
applications are easy to develop, parallel, fast, and resilient to failure, 
and they can operate on data from in-memory collections, local files, a Hadoop-
compatible filesystem, or from a variety of streaming sources. Spark also 
includes libraries for distributed machine learning and graph algorithms. 

== Scope ==
* Proposal owners: Currently our Spark package has been accepted into Fedora 
[1]. It features nearly all of the functionality available from the upstream 
release. (The missing features -- specifically, Python bindings, the Spark 
REPL, Kryo-based serialization, primitives for approximate cardinalities of 
very large sets, and Mesos integration -- were missing from the initial 
packages due to unavailable dependencies and bundling issues; we're working to 
close the gap with upstream as quickly as possible.) This work depended upon 
Fedora 21's improved support for the Scala ecosystem [2]. 
* 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] http://pkgs.fedoraproject.org/cgit/spark.git
[2] https://fedoraproject.org/wiki/Changes/ImprovedScalaEcosystem
___
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

Re: DSO API stability guidelines

[Michal Schmidt]

On 03/21/2014 01:18 PM, Neil Horman wrote:
> Can anyone point me to fedora packaging documentation that discusses
> the need for API stability in packaged shared libraries?  I'm sure we
> have some requirement that APIs in a DSO need to be versioned and
> maintained through a release, but for the life of me I'm unable to
> find it.

Hi Neil,

The Updates Policy for stable releases
(http://fedoraproject.org/wiki/Updates_Policy#Stable_Releases)
says this about ABIs, APIs:
  ABI changes in general are very strongly discouraged, they force
  larger update sets on users and they make life difficult for
  third-party packagers.
  [...]
  Package maintainers MUST:
Avoid Major version updates, ABI breakage or API changes if
at all possible. 

Michal
-- 
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 EPIC! [was Re: and SCL]

[Peter Lemenkov]

2014-03-21 16:07 GMT+04:00 Matthew Miller :

>> It doesn't exist, it's an idea that Robyn has floated semi-seriously
>> as a way to provide a repo that moves faster than EPEL. Rather than
>> try to jam fast-moving stuff in to EPEL, the idea was to do an Extra
>> Packages for Infrastructure and Cloud (EPIC) that had a different,
>> faster-moving charter. EPIC would target the *EL platform just as EPEL
>> does.

Faster moving rate is great indeed. But adding more than on version of
software (no matter of how many repos it takes) means only one - we
have to impose additional support requiremetns on a packagers.

The "social contract" requiremens for EPEL "support" (which of souce
isn't a "real" support) is way too high for the average maintainer.
That's the reason I believe the entire EPEL idea was a huge mistake
and waste of time - unfortunately I failed to discuss this with other
fellow fedora members during FOSDEM Fedora.NEXT related talks.

> I think this is a great place to try out what we can do with CentOS
> collaboration, since they're officially "in the family" now. Anyone have
> ideas on how best to proceed with that? New SIGs in both projects? A single
> new SIG spanning both? (CentOS's new SIGs seem to be a lot more heavyweight
> in terms of process than the concept we have for them in Fedora, for better
> or worse.) Some new joint upstream to be the meeting point?

No matter of the current situation I'd love to discuss possible ways
to improve it. So count me in as well.


-- 
With best regards, Peter Lemenkov.
___
epel-devel mailing list
epel-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Christian Schaller]

- Original Message -
> From: "Matthew Miller" 
> To: "Development discussions related to Fedora" 
> 
> Sent: Friday, March 21, 2014 12:59:01 PM
> Subject: Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next
> 
> On Fri, Mar 21, 2014 at 10:28:26AM +0100, Marcela Mašláňová wrote:
> > I agree with Jaroslav. I was looking forward to have a fourth
> > product to those three. KDE can help define what is needed for new
> > product, what must be done by all teams, how much work it will be
> > ... I guess we should speak more about addition of new product and
> > don't kill the idea at the start.
> 
> Like I said, I'm skeptical, but listening. :)
> 

While opinions differ on if we should 'ever' have more than 3 products, 
personally am very skeptical 
to the idea of product proliferation, I think that as a minimum common sense 
measure we should not even consider
any further products before we have the current 3 products released and our 
infrastructure updated to handle
them.

Christian
-- 
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: Improved Scala Ecosystem Support

[Jaroslav Reznik]

= Proposed Self Contained Change: Improved Scala Ecosystem Support  =
https://fedoraproject.org/wiki/Changes/ImprovedScalaEcosystem

Change owner(s): William Benton 

Fedora now supports several essential parts of the Scala language ecosystem as 
well as building packages with sbt, the de facto build tool for the Scala 
community. 

== Detailed Description ==
Fedora has had a Scala package for some time, but the larger Scala ecosystem 
has been absent from Fedora. In fact, until very recently, Fedora included no 
packages that depended on Scala. The main obstacle to getting Scala ecosystem 
projects packaged for Fedora was the difficulty in packaging sbt, the Simple 
Build Tool, which many Scala projects use for build, dependency, and release 
management. Fedora 21 now includes sbt as well as several interesting and 
foundational Scala ecosystem projects, most notably:

* akka, a toolkit for developing actor-based systems;
* json4s, a unified interface to JSON parsers and generators;
* sbinary, a typed Scala interface for reading and writing binary formats;
* sbt, the simple build tool for Scala and Java projects;
* scala-stm, a software transactional memory implementation for Scala;
* scalacheck, a property-based testing framework for Scala; and
* scalaz, a set of extensions to the Scala standard library to facilitate 
functional programming. 

== Scope ==
* Proposal owners:  The change is complete as described; other ecosystem 
packages and additional Fedora-specific developer documentation will continue 
to become available.
* 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)
___
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

DSO API stability guidelines

[Neil Horman]

Hey all-
Can anyone point me to fedora packaging documentation that discusses the
need for API stability in packaged shared libraries?  I'm sure we have some
requirement that APIs in a DSO need to be versioned and maintained through a
release, but for the life of me I'm unable to find it.

Thanks!
Neil

-- 
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: Java 8

[Jaroslav Reznik]

= Proposed System Wide Change: Java 8 =
https://fedoraproject.org/wiki/Changes/Java8

Change owner(s): Omair Majid 

Make Java 8 (provided by OpenJDK 8 which is java-1.8.0-openjdk) the default 
Java runtime. The current default Java runtime (Java 7, provided by OpenJDK 7, 
java-1.7.0-openjdk) will be obsoleted and removed.

This is essentially an upgrade to the latest Java and OpenJDK version. 

== Detailed Description ==
The current default Java 7 runtime in Fedora is OpenJDK 7. The latest version 
of OpenJDK, 8, was released on 18 March 2014. Given that Fedora 21 will not be 
released before August, it makes sense to include the latest version of 
OpenJDK in Fedora 21.

OpenJDK 8 is a significant update to Java. It brings in significant new 
features 
to the Java language, including lambdas, a new javascript engine and lots of 
new library features. A complete list of features is available [1].

OpenJDK 8 is a backwards compatible update. Theoretically everything that 
worked against OpenJDK 7 should continue working against OpenJDK 8. There are 
a few exceptions:

OpenJDK8 is much more strict when it comes to building javadocs. Many -
javadoc package in Fedora fail to build. Those that are built should continue 
working just fine.
Packages that rely on non-public OpenJDK API may fail to build/run. 

A complete list of incompatibilities is available [2]. The incompatibilities 
are source and behavioral only.

It may be a good idea to mass rebuild Java packages against OpenJDK 8 to spot 
any source incompatibilities earlier. This is not required.  

== Scope ==
* Proposal owners:
** Deprecate/Obsolete java-1.7.0-openjdk
** Promote java-1.8.0-openjdk to a full java runtime status (fix provides in 
package)
** In case of a mass rebuild, supply/apply patches to fix build against OpenJDK 
8

* Other developers:
** icedtea-web maintainers will need to update icedtea-web to run against 
OpenJDK 8
** Other java packagers will need to apply patches to their java package to 
ensure they can build against OpenJDK 8
** Everyone will need to test packages to verify that they work against 
OpenJDK 8

* Release engineering:
** Remove java-1.7.0-openjdk
** Possibly mass-rebuild (?) all Java packages. This is not strictly required 
to make OpenJDK 8 the default Java runtime.

* Policies and guidelines: 
** Many -javadoc packages fail to build. The OpenJDK 8 maintainers and the 
Java SIG are working on identifying a solution. The solution may require [3] 
guideline changes making -javadoc subpackages optional.

[1] http://openjdk.java.net/projects/jdk8/features 
[2] 
http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
[3] https://lists.fedoraproject.org/pipermail/devel/2014-March/196808.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

Re: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Matthew Miller]

On Fri, Mar 21, 2014 at 10:28:26AM +0100, Marcela Mašláňová wrote:
> I agree with Jaroslav. I was looking forward to have a fourth
> product to those three. KDE can help define what is needed for new
> product, what must be done by all teams, how much work it will be
> ... I guess we should speak more about addition of new product and
> don't kill the idea at the start.

Like I said, I'm skeptical, but listening. :)

-- 
Matthew Miller--   Fedora Project--
-- 
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: fail2ban + firewalld suggestions needed

[Matthew Miller]

On Thu, Mar 20, 2014 at 10:36:38PM -0600, Orion Poplawski wrote:
> > because the journal isn't optional in Fedora. And I think I'd combine
> > mail and sendmail (because the /usr/sbin/sendmail command can be
> > provided by a lot of alternatives, including the very lightweight
> > ssmtp).
> Yeah, I probably should just add the systemd config file to the main
> package.
> The -mail actions explicitly depend on /usr/bin/mail command which is
> only provided by mailx as far as I can tell.

True, but I'm having trouble imaging a case where someone wants fail2ban and
an MTA but really objects to having mailx installed, or wants fail2ban and
mailx but really objects to an MTA.


> > And maybe hostsdeny should be part of the main server package, as it really
> > just manipulates /etc/hosts.deny, which is part of the mandatory 'setup'
> > package.
> Yeah, but there's and entertaining thread about removing it...

Which actually I think argues for not bothering to subpackage it, doesn't
it? It'll be either there or not.

-- 
Matthew Miller--   Fedora Project--
-- 
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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Marcela Mašláňová]

On 03/21/2014 10:02 AM, Jaroslav Reznik wrote:

- Original Message -

On 03/19/2014 01:09 PM, Matthew Miller wrote:

There is also a proposal for a "Fedora Plasma" product based around KDE.
I'm
personally a little skeptical but listening -- I think want a technology
showcase masquerading as a product would miss the point, and I'd like to be
convinced that this is more than that.

We have an open question in FESCo over whether KDE should be release
blocking (there's a ticket for today's meeting), and there's some debate
over whether it's necessary for a desktop to be represented at the product
level in order to be considered blocking. (And I think that this issue is
driving the product push to some degree.)


My take on this is:

KDE should not be a top level Product. In my opinion, Fedora should only
produce the currently listed 3 Products and not more. Otherwise we get
back at square 1 where we have too many offerings and nobody knows what
makes a supported Fedora.
Kubuntu is to Ubuntu now.


I really can't agree with only three products doctrine forever. That's why
I personally call it multiple products initiative :). On the other hand I
completely agree with high bar pushed on products. So I don't expect we would
ever end with more than a few products - it's still manageable and it's the
message to the community - hey, we are still pretty much inclusive distro,
come and convince us, you can make it. We're Fedora, not Ubuntu - ask
Kubuntu guys for opinion :).

Also this high bar leads to another question - exactly opposite to the
escalation of spin to product. What if one of multiple products stops to
fulfil these high bar standards? I know, it does not make sense to have
policy for it now but it's just one piece of puzzle...

And believe me - during the release I wish we have only one product with one
package and one use case and one test. Life of many folks involved in
release would be much more happier :).

Jaroslav



--
Kalev,
Fedora Workstation WG

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


I agree with Jaroslav. I was looking forward to have a fourth product to 
those three. KDE can help define what is needed for new product, what 
must be done by all teams, how much work it will be ... I guess we 
should speak more about addition of new product and don't kill the idea 
at the start.


Marcela
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Bug 1071125] Upgrade to new upstream version

[bugzilla]

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



--- Comment #5 from Fedora Update System  ---
perl-Config-Validator-1.2-1.fc19 has been pushed to the Fedora 19 stable
repository.  If problems still persist, please make note of it in this bug
report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=xvY5YvtALv&a=cc_unsubscribe
--
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: Yet another bug caused by SELinux

[drago01]

On Thu, Mar 20, 2014 at 12:22 PM, Kevin Kofler  wrote:
> Hi,
>
> GHC (Haskell) was broken for (at least) over a year because of a bug in the
> workaround for stupid SELinux restrictions:
> https://ghc.haskell.org/trac/ghc/ticket/7629
> https://bugzilla.redhat.com/show_bug.cgi?id=907515
>
> How much breakage will we have to suffer until people finally realize that
> SELinux is a horribly flawed idea?

It does not matter how often you repeat that ... its not a "horribly
flawed idea".
-- 
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: Yet another bug caused by SELinux

[David Beveridge]

On Thu, Mar 20, 2014 at 9:22 PM, Kevin Kofler wrote:
>
> How much breakage will we have to suffer until people finally realize that
> SELinux is a horribly flawed idea?
>
> Kevin Kofler
>

I'm sure you are entitled to your opinion, and it is quite easy to disable
if that's what you want.
However, I quite like SELinux and have had very little trouble with it.
Needless to say, I disagree with you.

dave
-- 
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: Maybe it's time to get rid of tcpwrappers/tcpd?

[Gerd Hoffmann]

  Hi,

> So maybe a solution would be to write a libwrap2 instead ?

Don't think this is the solution.  Part of the problem is that some of
the functionality is just obsolete in todays world.  Trusting IDENT and
DNS for access control maybe made sense in the 90ies.  It certainly
doesn't today, and IMO lennart is correct in classifying this as
"security theater".

> So offer something with equivalent functionality (and config file
> syntax compatibility), with a nice modern clean API and then systemd
> and others can be moved over to that 1 by 1, and once we've no more
> users left we can kill of the old beast ?

I'd say moving the functionality which still makes sense (ip range based
checks) to the firewall is more useful.  Guess it shouldn't be that hard
to write a utility translating /etc/hosts.{allow,deny} into iptables
rules, or add support for that to firewalld.

Does tcpwrap support ipv6 btw?

cheers,
  Gerd

-- 
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: What will happen to XFCE, LXDE, Mate, Cinnemon in Fedora.Next

[Jaroslav Reznik]

- Original Message -
> On 03/19/2014 01:09 PM, Matthew Miller wrote:
> > There is also a proposal for a "Fedora Plasma" product based around KDE.
> > I'm
> > personally a little skeptical but listening -- I think want a technology
> > showcase masquerading as a product would miss the point, and I'd like to be
> > convinced that this is more than that.
> > 
> > We have an open question in FESCo over whether KDE should be release
> > blocking (there's a ticket for today's meeting), and there's some debate
> > over whether it's necessary for a desktop to be represented at the product
> > level in order to be considered blocking. (And I think that this issue is
> > driving the product push to some degree.)
> 
> My take on this is:
> 
> KDE should not be a top level Product. In my opinion, Fedora should only
> produce the currently listed 3 Products and not more. Otherwise we get
> back at square 1 where we have too many offerings and nobody knows what
> makes a supported Fedora.
> Kubuntu is to Ubuntu now.

I really can't agree with only three products doctrine forever. That's why
I personally call it multiple products initiative :). On the other hand I
completely agree with high bar pushed on products. So I don't expect we would
ever end with more than a few products - it's still manageable and it's the
message to the community - hey, we are still pretty much inclusive distro,
come and convince us, you can make it. We're Fedora, not Ubuntu - ask 
Kubuntu guys for opinion :).

Also this high bar leads to another question - exactly opposite to the 
escalation of spin to product. What if one of multiple products stops to
fulfil these high bar standards? I know, it does not make sense to have 
policy for it now but it's just one piece of puzzle...

And believe me - during the release I wish we have only one product with one
package and one use case and one test. Life of many folks involved in
release would be much more happier :). 

Jaroslav

> 
> --
> Kalev,
> Fedora Workstation WG
> 
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
-- 
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: Strange ssh / openldap linking problem

[Jan Synacek]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/20/2014 03:33 PM, Richard W.M. Jones wrote:
> Well this bug has reappeared on my machine.  openldap depends on
> openldap-devel.
> 
> $ ll /usr/lib64/libldap*
> lrwxrwxrwx. 1 root root 10 Feb 25 22:59 /usr/lib64/libldap-2.4.so.2 -> 
> libldap.so
> -rwxr-xr-x. 1 root root 340608 Feb  4 09:08 /usr/lib64/libldap-2.4.so.2.10.2
> lrwxrwxrwx. 1 root root 12 Feb 25 22:59 /usr/lib64/libldap_r-2.4.so.2 -> 
> libldap_r.so
> -rwxr-xr-x. 1 root root 365848 Feb  4 09:08 /usr/lib64/libldap_r-2.4.so.2.10.2
> lrwxrwxrwx. 1 root root 23 Feb 25 23:09 /usr/lib64/libldap_r.so -> 
> libldap_r-2.4.so.2.10.2
> lrwxrwxrwx. 1 root root 21 Feb 25 23:09 /usr/lib64/libldap.so -> 
> libldap-2.4.so.2.10.2
> 
> $ for f in /usr/lib64/libldap*; do echo -n "$f comes from "; rpm -qf "$f"; 
> done
> /usr/lib64/libldap-2.4.so.2 comes from openldap-2.4.39-2.fc20.x86_64
> /usr/lib64/libldap-2.4.so.2.10.2 comes from openldap-2.4.39-2.fc20.x86_64
> /usr/lib64/libldap_r-2.4.so.2 comes from openldap-2.4.39-2.fc20.x86_64
> /usr/lib64/libldap_r-2.4.so.2.10.2 comes from openldap-2.4.39-2.fc20.x86_64
> /usr/lib64/libldap_r.so comes from openldap-devel-2.4.39-2.fc20.x86_64
> /usr/lib64/libldap.so comes from openldap-devel-2.4.39-2.fc20.x86_64
> 
> This breaks libguestfs when it happens.
> 
> I've noticed that lots of people have hit this bug before:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=240253
> https://bugzilla.redhat.com/show_bug.cgi?id=248065
> https://bugzilla.redhat.com/show_bug.cgi?id=249866
> https://bugzilla.redhat.com/show_bug.cgi?id=447645
> https://bugzilla.redhat.com/show_bug.cgi?id=460307
> https://bugzilla.redhat.com/show_bug.cgi?id=693716
> https://bugzilla.redhat.com/show_bug.cgi?id=1028557
> 
> It's obviously a longstanding packaging bug in openldap and I think it
> needs to be fixed.
> 
> Rich.
> 

Thanks for the report. Let's continue in the bugzilla.

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

Cheers,
- -- 
Jan Synacek
Software Engineer, Red Hat
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTK/ZHAAoJEL3BmMJQOtjB8XAP/0RRpksu+aka5VCFQv5PaM93
BiuDMYT5V7bznXFDoC3D+Qi5hYKdKLYb3FBGerNGOZZe/DoLhGx2dZF8fJjh+FRE
XlcQw4/UHaA+7aYJKYYNgGbD6KTqHwXQZo1Hz06CK4T01Hp+eRzVYyXZTv8FD9Od
47ztfeHwd52zQ6Fe2JlJYj4D5d+KxMmYJkwFQAuSrwUDJJppoZ/Z2QWf2tbFZJ3V
etCRleB3cPueE4xcmVsDWrwxj+wE5x2ybbpfh2bA+WhSuf56V8qRRN+RZoQRhm3B
m63uDw/ItHuVzf/t7ym69+FynkyvnkOqOCvM0jF/gwNUJbuFaG2GiCjPiHLps1hl
ooSMaPgHYWbDdcl29IhJaD5qn1gaplhvH2LO+yfGIj7OwbeHN99GVyxg+0VMww0R
dSRhiwlyv14S700o3KDSvQ5qhHUOhdBgJRFlericznw70z5X8gju1xYcenkarzIX
ec/YOEkPFdw62zoih6UyByVLHKRTuPqapL9qQKwTc/fNM6q8ljQGjLlCebCeeDGc
m/J85dWmEpW2MimFDRBKksRKzqYfJ2A12RJo6snF5y7Xf/rfl5KfFkaUYzd1dEdz
Lfa1k/7Fl5SaA8QM868pL8zTPHIgHtu0FVQzhbIQlT0aOaOTJZ2zQE8mSSE+pDsA
hzBuKUGeL656j/r2Klwc
=pvuB
-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