Re: Incorrect order of /usr/bin and /usr/sbin in path

[Reindl Harald]

no, in general /usr/sbin is supposed to come before /usr/bin
and any software assuming the opposite has a bug

look what binaries are in /usr/sbin and then you know you really
don't want in general a bad package override them with place
a binary with the same name in /usr/bin

Am 04.05.2014 18:11, schrieb Ankur Sinha:
> Recently, the value of my PATH variable seems to be messed up:
> 
> 
>> [asinha@ankur-laptop  ~]$ echo $PATH
>> /usr/lib64/ccache:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/asinha/.local/bin:/home/asinha/bin
> 
> /usr/bin is supposed to come before /usr/sbin etc. This makes mock throw
> an error:
> 
> 
>> mock -r fedora-rawhide-x86_64 rebuild 
>> ./python-taskreport-1.2.1-1.fc20.src.rpm
>>
>> ERROR: [Errno 1] Operation not permitted
>>
>> ERROR: The most common cause for this error is trying to run /usr/sbin/mock 
>> as an unprivileged user.
>> ERROR: Check your path to make sure that /usr/bin/ is listed before 
>> /usr/sbin, or manually run /usr/bin/mock to see if that fixes this problem.
> 
> Running /usr/bin/mock.. works, of course. I've checked the relevant
> places, and everything seems to be in order. The EUID of my user is 1000
> too, so there isn't a reason that /etc/profile should place the
> directories incorrectly. Would anyone have an hints on correcting this?
> There's nothing in my user's .bash_profile or .bashrc that modifies path
> either. 
> 
> I use byobu with a tmux backend, but I don't think that matters. I
> opened a separate gnome-terminal without byobu and the EUID is correct
> there too. 
> 
>> [asinha@ankur-laptop  ~]$ id asinha
>> uid=1000(asinha) gid=1000(asinha) groups=1000(asinha),10(wheel),135(mock)



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

Re: F21 System Wide Change: Wayland

[Reindl Harald]

Am 03.05.2014 15:51, schrieb Rahul Sundaram:
> On Sat, May 3, 2014 at 9:27 AM, alex diavatis wrote:
> 
> From Fedora Docs (https://fedoraproject.org/wiki/Changes/Wayland)
> 
> >To avoid destabilizing the X compositor, mutter will ship two separate 
> libraries, and gnome-shell will ship two binaries that will link against 
> them. Concretely, we plan to have a separate mutter-wayland package.
> 
> Mutter-Wayland in GNOME 3.13.1 is merged to Mutter, so how can have 2 
> different packages?
> 
> Because Fedora 21 branch has GNOME 3.12

says who?

https://koji.fedoraproject.org/koji/buildinfo?buildID=514458

* Thu May 01 2014 Kalev Lember 
- 3.13.1-2 - Obsolete mutter-wayland
* Wed Apr 30 2014 Florian Müllner 
- 3.13.1-1 - Update to 3.13.1

https://koji.fedoraproject.org/koji/buildinfo?buildID=514690

* Fri May 02 2014 Kalev Lember  - 3.13.1-1
- Update to 3.13.1



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

Dracut HostOnly two releases later

[Reindl Harald]

looks like https://fedoraproject.org/wiki/Features/DracutHostOnly over
the long has the opposite effect and more and more modules are included
in the hostonly-initrd because regressions right and left

people who used hostonly before the feature on machines where
it is fine where down below 5 MB, with F19 around 6 MB and
on a completly stripped down F21/Rahide we reahc 9 MB

5,9M 2014-04-27 11:47 initramfs-3.13.11-100.fc19.x86_64.img
8,9M 2014-04-30 21:47 initramfs-3.15.0-0.rc3.git1.10.fc21.x86_64.img

finally nobody won and the ones with stripped down systems lost



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

Re: F21 System Wide Change: Default Local DNS Resolver

[Reindl Harald]

Am 30.04.2014 20:38, schrieb Dan Williams:
> There's really no guessing what's trusted/not-trusted unless you're
> using 802.1x/WPA Enterprise, or if the user has told you explicitly to
> trust this network

thank you!



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

Re: kernel packaging split up landing in Rawhide

[Reindl Harald]

Am 29.04.2014 23:41, schrieb Josh Boyer:
> As part of the F21 "Modular Kernel Packaging for Cloud" Feature[1],
> I've committed and pushed the kernel packaging split up into
> kernel-core and kernel-drivers subpackages.  For those of you running
> rawhide, this really shouldn't be a major impact at all.  When you do
> a yum update, you will see "kernel", "kernel-core", and
> "kernel-drivers" packages being installed.  The end result should be
> in line with today's rawhide kernels.
> 
> Note: Unless you're using a typical VM or Cloud image, don't uninstall
> the kernel or kernel-drivers packages.  The machine may boot with just
> kernel-core, but it will lack drivers for a significant portion of
> bare-metal hardware without kernel-drivers installed.
> 
> Despite best efforts in testing, it's always possible a bug or two
> snuck through.  In the event that you do have an issue with this,
> please file a bug against the kernel package.
> 
> josh
> 
> [1]https://fedoraproject.org/wiki/Changes/Modular_Kernel_Packaging_for_Cloud

thank you - looks pretty fine for VMware guests

[root@rawhide ~]# rpm -qa | grep kernel
kernel-core-3.15.0-0.rc3.git1.10.fc21.x86_64

[root@rawhide ~]# lsmod
Module  Size  Used by
zram   19948  2
crct10dif_pclmul   14268  0
crc32_pclmul   13133  0
crc32c_intel   22094  0
vmw_balloon13487  0
ghash_clmulni_intel13230  0
vmxnet353723  0
vmw_pvscsi 27370  2

[root@rawhide ~]# df
Filesystem Type  Size  Used Avail Use% Mounted on
/dev/sdb1  ext4   12G  682M   11G   6% /
/dev/sda1  ext4  487M   37M  447M   8% /boot



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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 23:33, schrieb Martin Langhoff:
> On Tue, Apr 29, 2014 at 5:28 PM, Chris Adams:
> 
> Once upon a time, Reindl Harald  > however, thank you to show me that any discussion with you is worthless
> 
> Right back at you.
> 
> The CoC does say a few things on this topic

follow the thread

> I am finding Reindl's trollish behavior extremely annoying.

> In my reading, 1% of his emails have some value, 99%
> are just winding people up :-(

ah, i noted security basics, Chris Adams says "no that's wrong" while you
say "principles are well understood in this group" which is *obviously*
otherwise it would not lead to that long discusssions and proposals like
disable the firewall at all and i am trollish?

interesting

i am not trollish, i just refuse to understand the partly
unaccepatble security and change for the sake of the change
attitude in many threads - not that i expect anybody get a
sepcialist, but sometimes it would be really helpful



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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 23:20, schrieb Chris Adams:
> Once upon a time, Reindl Harald  said:
>> defense in depth means limit the attack surface as much as you can
> 
> No, because "as much as you can" is turn the system off and bury it in
> concrete (with an armed guard).
> 
> The goal is "as much as practical". Trying to remove things that are
> needed is not practical

ok, now it is proven that you only try to quibbling

* the system needs to do a job
* turn it off means pretty clear it can't do it's job
* as much as you can means pretty clear not stop it's job

you can't tun it off because it's not practical

however, thank you to show me that any discussion with you is worthless
because you are more interested in words than in their content and
maybe be proud to be an native english speaker - congratulaitions for
that but it won't help that much at the end of the day



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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 23:09, schrieb Andrew Lutomirski:
> If you want to go down that path, set up selinux to prevent execing
> things that oughtn't to be execed.  But trying to prevent exploits
> from working by removing every possible helper from the path is a
> losing proposition and is just not worth doing

defense in depth means you are doing *both*
defense in depth means limit the attack surface as much as you can
defense in depth means place security layers behind others to surive a failing 
one
defense in depth means disable and remove anything which is not needed for your 
tasks



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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 23:00, schrieb Chris Adams:
> Once upon a time, Reindl Harald  said:
>> google as example for CVE-2014-0038 and as i already explained
>> you: a attacker has no shell, you have two ways to force a existing
>> local exploit by a web-application:
>>
>> A: try to get a complete script on the machine and execute it
>> B: find a very likely present binary and bring it to do the
>>rest of the attack for you with arbitary input
> 
> If I can run arbitrary code as your web user, I can do whatever 
> your web user can do

limited (why limited goes way too off-topic)

> If your kernel has a security hole, I can exploit that

surely, the point is how easy i can do that, do the instructions
somewhere how to do that work or not because they contain a
command / binary not available on the target system

> If I can run PHP code, there's a million things that I can do.  If I can
> run shell code, I can do just about as much.  How does the existence of
> a non-privileged systemd binary affect that?

given index.php?dumb_param=exploit_code

dumb_param gives exploit_code to shell_exec() or like function
you can't do whatever you like here simply be escaping

so you are very limited with your command
finally you need a abstraction in form of a binary doing harm with
the input which you can't pass directly to shell_exec limited
by input quoting

> I understand "defense in depth"

good

> I just don't believe the existence of a
> non-privileged systemd binary has a non-negligible effect on system (or
> container in this case) security.  If I can run an arbitrary binary on
> your system, you are already owned.  I can run /bin/sh (for example,
> just because it is nearly universal) and fetch other arbitrary binaries.

as explained you can't do that in any situation

> Do some binaries being available possibly make an attack easier?  Maybe,
> but that work is generally figured out once by "smart" people, and then
> exploited a million times by script kiddies.  Something being "harder"
> doesn't add anything mcuh to security, because it _can_ be figured out,
> will be, and then it'll be copy&pasted repeatedly (and you haven't
> gained a significant advantage from "it is harder")

surely because the copy&pasted instrcution may not work if it
relies on a default binary not installed in the container

in that case the attacker needs to adopt the exploit only for
you or he just goes to a server where his exploit code works
out of the box



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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 22:22, schrieb Chris Adams:
> Once upon a time, Reindl Harald  said:
>> don't get me wrong but you are talking bullshit
> 
> Put up or shut up

i shut when i say - not when you say

https://www.google.com/search?q=local+root+exploit+CVE

google as example for CVE-2014-0038 and as i already explained
you: a attacker has no shell, you have two ways to force a existing
local exploit by a web-application:

A: try to get a complete script on the machine and execute it
B: find a very likely present binary and bring it to do the
   rest of the attack for you with arbitary input

if you find B it's much easier because pass unsanitized input
to a web-script calling system() with it is one thing,
find a way to create a local file with whatever input you like
and execute it finally is a complete different world and needs
much more than one security problem in the web-application

>> you can't download whatever you like to do in any random situation
>> and excutue it like in a sehll - if you have only *one command* through
>> a web application you need to achieve that this single command triggers
>> the whole attack surface down to the critical component giving you
>> root access
> 
> If you can't explain how a non-privileged binary can result in a
> privilege escalation, then you are wrong. You need to go up-thread and
> read what I was responding to and show how it is wrong.

in case it don't sanitize user input, calling a already running
privileged  process and feed it with arbitary input damend

do you really pretend that never happened in the past?
and no i do not get paied to seek archives for you!




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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 21:59, schrieb Chris Adams:
> Once upon a time, Reindl Harald  said:
>> simple example:
>>
>> * binary XYZ is vulerable for privilege escalation
> 
> A local, non-privileged binary cannot be "vulerable for privilege
> escalation".  If I can run a non-privileged binary to escalate, then
> there is a problem with some other part of the system, not the binary.
> I can (unless severely locked down, which is difficult-to-impossible to
> do in practice) download another non-privileged binary and achieve the
> same privilege escalation

don't get me wrong but you are talking bullshit

you can't download whatever you like to do in any random situation
and excutue it like in a sehll - if you have only *one command* through
a web application you need to achieve that this single command triggers
the whole attack surface down to the critical component giving you
root access

you simply ignore the history of nearly any package coming with
security updates and CVE's where it's often even hard to believe
"how can this small piece have any security problem at all"


Am 29.04.2014 22:04, schrieb Andrew Lutomirski:
> Can you give an actual concrete example of wtf you're talking about?
> Because I suspect that you're completely wrong, but maybe you're right
> and no one on this thread understands what you're trying to say.

no i can't give you and example which replaces bother for more than
a decade in case of security in a single mailing-list thread

frankly feel free to ignore what people are telling you
these people continue also to feel free remove anything un-needed from systems

at the end of the day we will se who was right - the people tyring to make
things as secure as possible or the ones which would even not realize a
root-exploit on their machines after it has happened because in doubt you
have no chance to face it (given that the first thing a rootkit is doing
is to manipulate system-commands to hide itself)



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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 21:31, schrieb Daniel J Walsh:
> On 04/29/2014 03:17 PM, Chris Adams wrote:
>> Once upon a time, Reindl Harald  said:
>>> wrong question - is /bin/sh used?
>>> if the answer is yes then the anser to your question is no
>>>
>>> the point is remove anything *unneeded* from production systems
>>> that are best practices for many years and for good reasons
>> No, the point is that "remove a bunch of stuff to 'secure' the system"
>> is not security, and should not be claimed that it is being done for
>> 'security'.  If you have bash as /bin/sh (as a 'standard' Fedora system
>> does), you don't need wget/curl to download stuff for example.
>>
>> Can you lock that down more?  Sure, you can remove network access,
>> remove local write access, etc.  However, that is separate from removing
>> arbitrary binaries from the system/image.  Removing non-privileged
>> binaries from the image does _nothing_ for security (as claimed
>> up-thread).
>>
> I am looking at this from a tools perspective.  If I run an scap tool
> that says container image XYZ has a vulnerable image of udev, even if
> udev is not being used, I will have to update the image.  If it does not
> have the package, no reason to update

exactly *that* is the problem people never had to work the one
or other way in security business not understanding

if you have external security audits there is no "can this be a problem"
you finally get "fix that within 24 hours or shutdown" with no choice

been there and while 100% sure the audit result is from the category
"a fool with a tool is still a fool" no choice to ignore it and god
beware you manage to explain that it is not relevant followed by
a real exploit two days later



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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 21:36, schrieb Andrew Lutomirski:
> On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald  
> wrote:
>> simple example:
>>
>> * binary XYZ is vulerable for privilege escalation
> 
> This makes no sense...

for you

>> * we talk about a *local* exploit until now
> 
> ...I don't even know what you're trying to say here...

than google for

* "privilege escalation"
* "local exploit"
* "remote exploit"

that could be a good start:
http://en.wikipedia.org/wiki/Exploit_%28computer_security%29

>> * a bad configured webserver allows system-commands through a php-script
>>   and i consider that you google for the /e modifier
> 
> ...and this is already sufficient for a remote exploit.

yes, but the difference may be if you only can run unprivileged
code or have a chance to own the machine and get root

> Can we please move all discussion of "Zomg! This feature would take an
> existing security hole and turn it into a security hole with exactly
> the same impact" into its own thread or just stop it entirely?  All it
> does is distract from real discussion

can you please start to goole for things others talking about?



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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 21:17, schrieb Chris Adams:
> Once upon a time, Reindl Harald  said:
>> wrong question - is /bin/sh used?
>> if the answer is yes then the anser to your question is no
>>
>> the point is remove anything *unneeded* from production systems
>> that are best practices for many years and for good reasons
> 
> No, the point is that "remove a bunch of stuff to 'secure' the system"
> is not security, and should not be claimed that it is being done for
> 'security'.  If you have bash as /bin/sh (as a 'standard' Fedora system
> does), you don't need wget/curl to download stuff for example.
> 
> Can you lock that down more?  Sure, you can remove network access,
> remove local write access, etc.  However, that is separate from removing
> arbitrary binaries from the system/image.  Removing non-privileged
> binaries from the image does _nothing_ for security (as claimed
> up-thread)

simple example:

* binary XYZ is vulerable for privilege escalation
* we talk about a *local* exploit until now
* a bad configured webserver allows system-commands through a php-script
  and i consider that you google for the /e modifier
* a exploit for the web application triggers that binary
* voila you have a *remote* privilege escalation to get root access

*that* is how attacks can work if things are going wrong
you may now come with how likely that happens

it's not a matter of how likely, it happened in the past and it
will happen in the future and every time such things happened
people came with "i did not imagine that this could be possible"

so learn from the past, realize that things are possible and
reduce the attack surface for the imaginary you don't believe

well, you can ignore that and still pretend "that is not security"
others did that too in many cases learning it the hard way



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

Re: We want to stop systemd from being added to docker images, because of rpm requiring systemctl.

[Reindl Harald]

Am 29.04.2014 20:51, schrieb Chris Adams:
> Once upon a time, Marcelo Ricardo Leitner  said:
>> You're considering only the escalation way to do it, but there are
>> other ways to exploit code laying around, like when some web pages
>> don't sanitize the URL enough and end up allowing executing
>> something in the system, much like sql injection. In those cases,
>> one could craft URLs to run wget or any other tool that may help the
>> intruder get even more inside.
> 
> Down that path lies madness.  Are you going to remove /bin/sh?  If not,
> virtually anything else is possible

wrong question - is /bin/sh used?
if the answer is yes then the anser to your question is no

the point is remove anything *unneeded* from production systems
that are best practices for many years and for good reasons

anything which is not present can't make troubles

* security
* things get enabeld by bugs
* wasted space (keep backups in mind, especially off-site backups)
* possible dependecy problems

on cloud-systems (to play bullshit-bingo) or simply virtualized
infrastructure you pay multiple times for any overhead and if
the case happens that you pay for a security problem this is
also multiplied

that's why on hardened systems mostly customized packages are
installed and the most interesting outputs of ./configure --help
are the ones starting with "--without" and "--disable"



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

Re: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...

[Reindl Harald]

Am 28.04.2014 19:36, schrieb Miloslav Trmač:
> 2014-04-28 19:33 GMT+02:00 Reindl Harald  <mailto:h.rei...@thelounge.net>>:
> 
> Am 28.04.2014 19:27, schrieb Miloslav Trmač:
> > 2014-04-28 19:13 GMT+02:00 Reindl Harald:
> > you can make signed fedora packages trusted and allow them
> > at install or first start to interact with firewalld
> >
> > I can't; ptrace() doesn't make such a distinction.
> 
> than that needs to be improved
> 
> We are working on improving it.  It will still take quite a lot of time I'm 
> afraid.

so the status quo needs to be unchanged until then

> > Still, the combined measures need to mitigate at least, say, 75% of 
> cases,
> > otherwise we're not really having enough impact
> 
> in a perfect world yes, even more than 75%
> 
> in reality: only *the one an donly* case which affects me untila update 
> is released
> we need the > 75% because we don't know what is needed when
>  
> Good point, the "new system needs to be safely updatable" is an important 
> case to consider.  (It's also the easiest
> one to handle, by not having the service start, and testing for that.)

you can't do that
even if you could in theory it must not be the only safety net

you choose at installation software XYZ wich may listen on ports
that's the whole argumentation of dropping the firewall to make
these things working out-of-theb-box the easy way

there is a timewindow between installation and get the latest updates
well, you need the network to fetch that updates

and what is permanently ignored here and proves that the proposal
disable the firewall completly is a clueless ignoring reality
is that "i want saba to share files" *never ever* means "oh
and samba should be reachable from the internet"

in no case - independent of possible vulerabilities which needs to be
closed by fetch updates over the internet you want smaba be reachable
on the WAN and the one idiot out of a million which wants that don't
really so - he just don't know what he really wants

one of the goals of sane and secure OS defaults is to protect
users from themself

even if the only thing you reach is a timewindow from start to find out
how to disable the firewall until find how to do to think about that
idea and come to the conclusion do that unconditionally is a bad idea
you reached a lot -> a handful users not doing so



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: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...

[Reindl Harald]

Am 28.04.2014 19:27, schrieb Miloslav Trmač:
> 2014-04-28 19:13 GMT+02:00 Reindl Harald:
> > Well if the users' expectations were that the firewall doesn't 
> "interfere" with Fedora applications, why
> would they
> > expect it to "interfere" with non-Fedora applications?
> 
> do i really need to explain that?
> 
> you can make signed fedora packages trusted and allow them
> at install or first start to interact with firewalld
> 
> I can't; ptrace() doesn't make such a distinction.

than that needs to be improved or the current status no open ports at
all without user confirmation unchanged

> > And doesn't every malware know to make an _outgoing_ connection to an 
> IRC server nowadays?
> > Stopping malware by blocking incoming connections is fairly illusory 
> IMHO
> 
> i find it pervert that such basics need to be discussed
> 
> * you can't reach 100% security, never, in no way
> 
> Still, the combined measures need to mitigate at least, say, 75% of cases, 
> otherwise we're not really having enough impact

in a perfect world yes, even more than 75%

in reality: only *the one an donly* case which affects me untila update is 
released
we need the > 75% because we don't know what is needed when

but even if we reach only 25% it's better than 0% by giving up and drop the 
firewall

it makes me really sad that anybody ever can come to an idea disable the
firewall as default because it makes things harder and that it needs
discussions after 1st of April - are such people payed by the NSA and
sent out to destory sceurity everywhere?



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: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...

[Reindl Harald]

Am 28.04.2014 19:04, schrieb Miloslav Trmač:
> 2014-04-28 18:59 GMT+02:00 Reindl Harald  <mailto:h.rei...@thelounge.net>>:
> 
> Am 28.04.2014 18:52, schrieb Miloslav Trmač:
> > No no no no no.  If you want a firewall "integrated" /that/ way, you 
> are really
> > better of uninstalling it or opening it up; it serves no purpose.
> 
> no, even if that way is completly wrong it's better than no firewall
> as i have explained multiple times there may run software not from
> the Fedora repos which opens ports unintentionally from the users
> point of view and especially a user with no network expierience
> will not realize that - and yes that software matters because
> we are talking about a *operating system*
> 
> Well if the users' expectations were that the firewall doesn't "interfere" 
> with Fedora applications, why would they
> expect it to "interfere" with non-Fedora applications?

do i really need to explain that?

you can make signed fedora packages trusted and allow them
at install or first start to interact with firewalld

you can't do that for http://www.zend.com/de/products/studio/downloads
you can't also explain zend they should not open ports with a IDE
you can't do the same for any other software manufacturer
you can#t do that even Fedora, see the thread-start for the sake of god

security don't work the way what people should do
security works the way "what could people do wrong"

> the next thing is when it comes to malware opening ports
> there are two types of malware:
> 
> * privilege escalation (you have lost)
> * crap try to open a unprivileged port with user permissions
> 
> The second case is a subset of the first one anyway :)

no - privilege escalation is meant as get root permissions

> And doesn't every malware know to make an _outgoing_ connection to an IRC 
> server nowadays?  
> Stopping malware by blocking incoming connections is fairly illusory IMHO

i find it pervert that such basics need to be discussed

* you can't reahc 100% security, never, in no way
* you can only try to make it as tightas possible
* each of your protections will stop some bad cases
* enough of them with some luck the one user A, B, C would have hitted before 
updates

do you *really* not want to understand what people explaining?
http://www.zend.com/de/products/studio/downloads opens ports
to talk inside the LAN and prohibit starting the product on
two machines with the same licencse key

*YOU DO NOT WANT THAT PORTS OPEN ON THE INTERNET BECAUSE WRONG OS-DECISIONS*

and that is besides VMware the only software not coming via yum in my case
1 out of 2 commercial products should failry explain why nobody right in
his brain designs in 2014 a operating system with no packet filter at all



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: an that is why we need a firewall -> Re: When a yum update sets up an MTA ...

[Reindl Harald]

Am 28.04.2014 18:52, schrieb Miloslav Trmač:
> 2014-04-28 12:42 GMT+02:00 David Woodhouse  <mailto:dw...@infradead.org>>:
> 
> On Mon, 2014-04-21 at 09:42 +0200, Reindl Harald wrote:
> > Am 21.04.2014 03:39, schrieb Lars Seipel:
> > > Nicely aligning with the current firewall thread I noticed that one of
> > > my machines was running the exim MTA for the last few days, dutifully
> > > listening on all interfaces
> >
> > and now it is *proven for sure* that disable the firewall
> > by default is the most dumb thing a distribution can do
> 
> This doesn't make much sense to me.
> 
> Take a look at the wording of the proposed change: "The current level of
> integration into the desktop and applications does not justify enabling
> the firewalld service by default."
> 
> Now imagine the situation if we take the opposite approach — we *fix*
> the integration, and leave it enabled by default.
> 
> Fixing the integration means that installing packages which need to
> listen on a network socket should Just Work™. That means they'll talk to
> firewalld somehow, to enable their ports.
> 
> No no no no no.  If you want a firewall "integrated" /that/ way, you are 
> really
> better of uninstalling it or opening it up; it serves no purpose.

no, even if that way is completly wrong it's better than no firewall
as i have explained multiple times there may run software not from
the Fedora repos which opens ports unintentionally from the users
point of view and especially a user with no network expierience
will not realize that - and yes that software matters because
we are talking about a *operating system*

the next thing is when it comes to malware opening ports
there are two types of malware:

* privilege escalation (you have lost)
* crap try to open a unprivileged port with user permissions

the second one has to be stopped and please don't come with "that
could be stopped with SElinux" -> layered security

you need to tealize security as a big picture with as much
defense layers as possible and whoever thinks "no, this
and that leayer is not needed because we have A, B, C" has
no clue about security at all and nothing learned in the last
few years from things which happened in the wild



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: and that is why we need a firewall -> Re: When a yum update sets up an MTA ...

[Reindl Harald]

Am 28.04.2014 12:42, schrieb David Woodhouse:
> On Mon, 2014-04-21 at 09:42 +0200, Reindl Harald wrote:
>>
>> Am 21.04.2014 03:39, schrieb Lars Seipel:
>>> Nicely aligning with the current firewall thread I noticed that one of
>>> my machines was running the exim MTA for the last few days, dutifully
>>> listening on all interfaces
>>
>> and now it is *proven for sure* that disable the firewall
>> by default is the most dumb thing a distribution can do
> 
> This doesn't make much sense to me

what exactly?

that open port 25 by a package error on the WAN is critical?
that open whatever port by a package error on the WAN is critical?

> Take a look at the wording of the proposed change: "The current level of
> integration into the desktop and applications does not justify enabling
> the firewalld service by default."

i know that wording

> Now imagine the situation if we take the opposite approach — we *fix*
> the integration, and leave it enabled by default.

yes

> Fixing the integration means that installing packages which need to
> listen on a network socket should Just Work™. That means they'll talk to
> firewalld somehow, to enable their ports.

yes but not *all ports* and not uncomprehensive at all

you really don't want to open SMB on the WAN because you
want to share a folder  

> We need that, because from a usability point of view it just isn't
> acceptable to have things which *appear* to work when you test them from
> localhost, but silently fail when you connect from the outside. That's a
> really insidious failure mode which has bitten me a number of times when
> I've forgotten to turn off the misguided firewall on a newly-installed
> machine.

the user needs a way to decide where the port should be open

* local network
* wan
* only localhost

> So when it's all finished and working properly, the firewall doesn't
> really buy you anything in this case. A package which is set up to
> listen by default will still do that, and it'll still be a bug in the
> package in question.

*no not on the WAN*

what you really refuse to understand is the implication of disable the
firewall at all - frankly in the early KDE4 days there where ports
from KDE applications listening on 0.0.0.0 which where for sure never
intended to be reachable from the internet - yes that was all bugs

but realize that we can't pretend to live in a bugfree world

that would mean these ports below would be open to the internet - that's
just ZendStudio (not a fedora package) where due start it tries to check
if there is already a instance running on another computer with the
same serial, not you nor i have to justify that, that's real life as it is

if you don't care about such cases stop to pretend you are building
an operating system - on an operating system there is a world outside
the distributions repos

[root@rh:~]$ netstat -l | grep java
tcp0  0 0.0.0.0:10137   0.0.0.0:*   LISTEN  
15717/java
tcp0  0 0.0.0.0:90000.0.0.0:*   LISTEN  
15717/java
tcp0  0 0.0.0.0:20080   0.0.0.0:*   LISTEN  
15717/java
udp0  0 0.0.0.0:43210.0.0.0:*   
15717/java

> You can make sure that only the MTA is listening on port
> 25 and not anything else

and even if - have a MTA reachable on the WAN after installing it
before you have configured it for proudction use if you even intend
to do that is the most possible dumb thing

that said from a professional mailserver admin!



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: [RFC] plans for initscripts in F22

[Reindl Harald]

Am 26.04.2014 11:24, schrieb Michael Scherer:
> Le vendredi 25 avril 2014 à 19:30 +0200, Miloslav Trmač a écrit :
>> And it's not only commercial software; private projects that make no
>> sense to publish (such as a company's web site) are equally affected
>> such changes. Simply spoken, if we care only about package in Fedora,
>> we are building an appliance; if we want to build an operating system,
>> we do need to cater for software not included directly in the repo.
> 
> Then how can we signal to people that they need to update those
> packages ?

the problem is that people don't want to rewrite/update
perfectly working things which are broken by intention

moving config files around or replace them with a completly
new syntax because the rewrite of whatever piece of software
did not have backwards compatibility in mind is annoying for
a lot of reasons - besides some voices saying "i don't care
about anything which is not part of the distribution"

* it breaks working setups
* it renders howtos invalid
* it throws away knowledge of people that learned how to do things

it's already a big problem that if you try to achieve something you can't
rely on any information you find in the internet if it's not brand new
written

with stable interfaces and configurations you can build on top of several
articles and howtos pieces together for your solution

by permenantly changing interfaces (CLI params are user-interfaces) that
ends in 3 of 5 pieces are still working that way but the big picture fails
by the 2 no longer behave that way parts and if you try something you did
never before and not sure what is the best way at all it get's really hard


i have built a lot of automation for systems administration that way over
years where machines for different services are configuring themself by
meta-informations coming from simple actions like "fill out one webform
for a new domain"

* register that domain via EPP
* add the domain to the DNS servers
* add the domain on the primary webserver and create a document root
* create a mysql database
* install our self written cms with a default setup and configure it for that 
database
* add the domain including whois-infos to the billing database
* add the email addresses to dbmail
* add the domain
* add the domain to the spamfirewall-appliance
* add a SPF record to 4 nameservers with LAN/WAN DNS views
* configure autoconfig/autodiscover aliases on apache and add the DNS records
* add the domain on the Trafficserver machine (ATS and local dnsmasq) to
  later decide with a single DNS change if it needs load-balancing

that can be one big task and several cronjobs on several machines are doing that
one time, but all these jobs also working alone for cases where no mail 
addresses
where ordered and 6 months later are needed - well, enter the mail-addresses in
a textfield, the above tasks which are relevant are happening and the result is
a list with username:generated-password

so all that pieces are running standalone but also heavily combined
if one of them falls because a change in the distribution the damage
depends on which one, can it be automatically detected and following
actions stopped while raise alarm, how can you test the cases which
may lead to failing one of the pieces, how do you manage to test the
behvior if the underlying operating system make abusive changes

and last but not least even if you know which things are changing
in case of dist-upgrades how do you plan these changes in case we
are talking about a lot of machines acting together since a distupgrade
on a ton of machines is a non-atmoic process and you hardly can stop
the whole infrastruture

until now i managed to surivive dist-upgrades from Fedora 9 to 19 in such
a environment inluding make space for GRUB2 with test-machines and dd-dumps
of the (luckily) /boot-disks instead partitions distributed but that don't
mean you ask yourself not if the current change is really worth the impact


if you managed to get your result after that and the next Fedora
version breaks it again because someone says "ah that was a terrible
way to do things, we no longer support that please change that" and
that happens too often it raises the question "is Fedora something you
can build things on top of which is the job of an operating system or
is Fedora something narcissistic you should avoid if you don't want to
rebuild your work every few years or sometimes months"

don't get me wrong, i am a perfectionist too re-factoring and optimizing
my code up to comments and seek even wrong code-indenting of single lines
while trying to get rid of code better never written that way - but doing
that you need to draw a line where you better should stop because the damage
defeats the positive effect and if you are not drawing that line you end
in a loop of breaking, replacing, adopting, breaking, replacing, adopti

Re: [RFC] plans for initscripts in F22

[Reindl Harald]

Am 26.04.2014 02:01, schrieb Jóhann B. Guðmundsson:
> On 04/25/2014 10:53 PM, Miloslav Trmač wrote:
>> I don't think our foundations ever implied that we need or want to be a 
>> closed ecosystem restricted to only the
>> repository we produce.  The just don't address this.
> 
> You must understand we cannot keep back process in the distribution, be it 
> cleanup or advancement based on some 3rd
> party requirements out there since we are as powerless to help them as we are 
> with proprietary components.

you must understand that you can't do any "cleanup" coming to your mind if you 
are
building an *operating system* without care for the real use cases out there or 
you
will and in a very clean environment nobody but you will use over the long 
because
nobody wants to work with a operatiung system where every few weeks thins left 
and
right are falling down

progress is not defined by destory others environments for a theoretical better 
future
because the way some hardline "cleanupers" will never stop acting that way and 
begin to
deprecate things which *now* you are telling everybody has to migrate to to 
deprecate
3 years later

a *operating system* is *the base* for others work and as long  some people 
don't understand
that they are doing harm not only to the distribution and the current users, 
they damage Linux
as a whole ecosystem because nobody right in his mind will migrate to a 
operating system where
his work is destroyed every few months or years

*that is* why microsoft is that sucessful while they are shipping technical 
crap - you have to
find a way to develop and improve things without breaking careless left and 
right around you or
you end meaningless - the way of such development is replace code but keep 
interfaces and
configurations compatible and unchanged - yes that's harder than throw away 
anything when
ever you like to do so and start from scratch - but if you don't want to do 
this you
should not pretend you are developing an operating syteem

*you* fear Fedora ends meaningless if the progress is not fast enough?

the reality is Fedora ends meaningless if it is only a technical playground 
with no stability
in interfaces endusers and developers outside the distribution can build on top 
of and the
reason why Unix and unix-like systems are survived that many years are stable 
interfaces until
a few years ago the "throw away and break anything"-attitude started that much



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: [RFC] plans for initscripts in F22

[Reindl Harald]

Am 25.04.2014 19:30, schrieb Miloslav Trmač:
> 2014-04-25 12:40 GMT+02:00 "Jóhann B. Guðmundsson":
> Which is what we care about we cannot hold back progress in the 
> distribution based on someone, someplace,
> somewhere might be using legacy cruff.
> 
> It's better for everybody they themselves included that they maintain 
> those packages or components within
> Fedora itself or those individuals or company's will need to adapt they 
> themselves to our changes when we make
> them.
> That's certainly an option but it's not the only one; see the recent 
> "Functional" threads for example.
> 
> For LSB, there is an /explicit promise/ that if a vendor does what is 
> specified, the package will be possible to
> install and will run correctly.  We do, of course, have the option to 
> repudiate LSB and explicitly say we don't
> care for future releases.
> 
> And it's not only commercial software; private projects that make no sense to 
> publish (such as a company's web
> site) are equally affected such changes. Simply spoken, if we care only about 
> package in Fedora, we are building an
> appliance; if we want to build an operating system, we do need to cater for 
> software not included directly in the repo

*thank you* for that words!



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: gcc build with -O0 results in corrupted -debuginfo package

[Reindl Harald]

Am 25.04.2014 17:10, schrieb Adam Jackson:
> On Fri, 2014-04-25 at 16:50 +0200, Reindl Harald wrote:
> 
>> but it don't justify incompatible flags
>> IMHO you enter the area of "undefined behavior" with that
> 
> Your humble opinion is misguided, building without _FORTIFY_SOURCE is an
> entirely reasonable thing for an end developer to want to do on their
> machine, and one we should support

sorry, but you misunderstood me

what i said was the combination of -O0 *and* -D_FORTIFY_SOURCE=2
or specifically "$CFLAGS $RPM_OPT_FLAGS -O0"at the same time feels
like undefined behavior because that contains a lot of default
flags including -D_FORTIFY_SOURCE=2



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: gcc build with -O0 results in corrupted -debuginfo package

[Reindl Harald]

Am 25.04.2014 16:43, schrieb Petr Spacek:
> On 25.4.2014 16:28, Reindl Harald wrote:
>> Am 25.04.2014 16:10, schrieb Petr Spacek:
>>> I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
>>> CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
>>>
>>> I did the simplest possible thing - edited the original spec file (see 
>>> spec.diff) and built the package:
>>> $ rpmbuild -ba bind.spec
>>>
>>> The package builds and BIND itself seems to work. The problem is that new 
>>> debuginfo package is missing 118 out of
>>> 283 header files in /usr/src/debug/bind-9.9.4-P2.
>>>
>>> It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem.
>>>
>>> I would be glad if anyone can give me advice how to debug this.
>>>
>>> Original packages from Fedora 20 (with all headers in /usr/src/debug):
>>> http://koji.fedoraproject.org/koji/buildinfo?buildID=502596
>>>
>>> Packages built with -O0 -ggdb (scratch build):
>>> http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483
>>
>> just don't do that
> I'm going to reproduce and debug issue in named. Do you see any specific 
> reason 
> why I should use -O2 for serious debugging/development sessions?

no but then don't include $CFLAGS $RPM_OPT_FLAGS

>> and read compiler warnings
> Thank you very much for your very helpful advice! :-)
> 
>> the debuginfo package is your smallest problem
> I'm afraid it is not

please look at the whole picture of the FLAGS you are using

>> you just kill security features like D_FORTIFY_SOURCE with -O0
>>
>> warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
>> [-Wcpp]
> I think my use case justifies it

but it don't justify incompatible flags
IMHO you enter the area of "undefined behavior" with that

-D_FORTIFY_SOURCE=2 is part of the Fedora default flags



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: gcc build with -O0 results in corrupted -debuginfo package

[Reindl Harald]

Am 25.04.2014 16:10, schrieb Petr Spacek:
> I'm trying to rebuild bind-9.9.4-12.P2.fc20.src.rpm with
> CFLAGS="$CFLAGS $RPM_OPT_FLAGS -O0 -ggdb".
> 
> I did the simplest possible thing - edited the original spec file (see 
> spec.diff) and built the package:
> $ rpmbuild -ba bind.spec
> 
> The package builds and BIND itself seems to work. The problem is that new 
> debuginfo package is missing 118 out of
> 283 header files in /usr/src/debug/bind-9.9.4-P2.
> 
> It seems that "-O0" alone (instead of "-O0 -ggdb") causes the same problem.
> 
> I would be glad if anyone can give me advice how to debug this.
> 
> Original packages from Fedora 20 (with all headers in /usr/src/debug):
> http://koji.fedoraproject.org/koji/buildinfo?buildID=502596
> 
> Packages built with -O0 -ggdb (scratch build):
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6778483

just don't do that and read compiler warnings
the debuginfo package is your smallest problem
you just kill security features like D_FORTIFY_SOURCE with -O0

warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) 
[-Wcpp]




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: [RFC] plans for initscripts in F22

[Reindl Harald]

Am 25.04.2014 13:12, schrieb Lukáš Nykrýn:
> Dne 25.4.2014 12:50, Reindl Harald napsal(a):
>> Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
>>> On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
>>>>
>>>> Only those that are maintained directly inside Fedora.
>>>
>>> Which is what we care about we cannot hold back progress in the
>>> distribution based on someone, someplace, somewhere might be using
>>> legacy cruff.
>>
>> have you ever heard "if it ain't broken don't fix it"
>> network.service works fine until someone decides to break it intentionally
>>
> network initscript *is* broken

no - such generalizations are always wrong
it does not fit for every setup and it don't pretend that

proven by over 30 F19/F20 setups in a wide range from virtualized servers
with simple setups to physical hardware with multiple network cards, virtual
TAP devices acting as  routers, firewalls, WLAN accesspoints and VPN servers
with up to 5 decdicated openvpn-instances with their own keys, ports and
TAP devices it works for a lot of environments and they never will change
because that is why virtualization is used

> During rhel7 beta I have discovered a lot of design flaws when people tried 
> to use
> it on some advance hardware. Boot in fedora is now quite asynchronous and 
> network 
> is unable to cope with that. For example we have already removed the hotplug 
> script.

network.service is not for hotplug
it is for static configurations

> And I really don't want to end with NM on laptops, network on simple servers 
> and networkd elsewhere

i really won't end with NM on simple virtual servers with one virtual NIC
so just don't break network.service intentionally because it does not fit
your usecases

i don't demand you to you use network.service so don#t demand others
using NM and completly rebuild complex working setups - that's not
progress, that's just making development-noise to let people feel
there was done some work the hard way and they have to chew it



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: [RFC] plans for initscripts in F22

[Reindl Harald]

Am 25.04.2014 12:58, schrieb Jóhann B. Guðmundsson:
> On 04/25/2014 10:50 AM, Reindl Harald wrote:
>>
>> Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
>>> On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
>>>> Only those that are maintained directly inside Fedora.
>>> Which is what we care about we cannot hold back progress in the
>>> distribution based on someone, someplace, somewhere might be using
>>> legacy cruff
>>
>> have you ever heard "if it ain't broken don't fix it"
>> network.service works fine until someone decides to break it intentionally
> 
> Completely Irrelevant to my response since what I was referring to was 
> components maintained outside Fedora.

when i have learned something than if someone in context of Fedora
development uses words like "legacy cruff" and "deprecate" that the
next step is try to remove and no longer support it

there is a reason why i get alarmed by the word "legacy"



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: [RFC] plans for initscripts in F22

[Reindl Harald]

Am 25.04.2014 12:40, schrieb Jóhann B. Guðmundsson:
> On 04/24/2014 04:30 PM, Miloslav Trmač wrote:
>>
>> Only those that are maintained directly inside Fedora.
> 
> Which is what we care about we cannot hold back progress in the 
> distribution based on someone, someplace, somewhere might be using 
> legacy cruff.

have you ever heard "if it ain't broken don't fix it"
network.service works fine until someone decides to break it intentionally




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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 23.04.2014 07:52, schrieb Liam:
> On Apr 22, 2014 5:09 AM, "Christian Schaller" wrote:
>> I think this is a misunderstanding of who a developer might be and why they 
>> choose
>> a system. Those of my friends and acquaintances, who are developers and who 
>> over the
>> years have decided to switch their development laptops from Linux to 
>> predominantly
>> MacOS X, has not done so because they had things they wanted to do that was
>> 'impossible' to do with Linux or that they thought they could not figure out 
>> how to
>> do with linux. Instead they moved because they got tired of spending time 
>> trying to
>> make their system 'work'. This is in no way limited to dealing with the 
>> challenges
>> of a firewall, but if we want to attract developers or any kind of user to 
>> our
>> system we need to make it usable without needing daily google searches
>> to figure out how you can do something and make parts of your system work.

the daily google searches are much more because interfaces are permanently
replaced - be it GUI's or CLI interfaces and configurations get invalid
due all that replacements - *there* is the problem - what you know today
maybe in 3 years as ivalid as what you learend 5 years ago about a Fedora
system and whatever you find with Google is quentionable and likely outdated

smart replacements whould keep interfaces as they are and only replace
the code behind and add some options but not break the semantic

> The fact of the matter is that there's really no compelling reason for the 
> average web 
> developer, for instance, to move to Linux. Osx is already more powerful than 
> any linux 

stop that

i face every single day the opposite because on the other side
of my desk is a OSX machine, terrible slow with the same CPU and
a unacceptable usability compared with a recent KDE because you
can't do this and that

the usability part may be subjectively, the terrible slow is not
given both of our machines have the same CPU





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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 22.04.2014 19:01, schrieb Miloslav Trmač:
> 2014-04-22 13:40 GMT+02:00 Stephen Gallagher  >:
> 
> 3) Recovery and auditing are more important than prevention.
> 
> This is /only/ true for large managed enterprises, where recovery is possible 
> in the first place (how many people
> don't have good backups?), and prevention is bordering on impossible (with 
> the high number of systems and
> administrators).  For individual users auditing is completely pointless, 
> recovery is either impossible or a huge
> hassle, and prevention the only option.

and with *every* recovery you lose unconditional data
you can't have perfect backups in real time not containing the issue too

sorry, but after working 11 years without a need to recover
i say recovery is nice and should be possible, but if you
need it regulary you are doing something wrong



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: and that is why we need a firewall -> Re: When a yum update sets up an MTA ...

[Reindl Harald]

Am 21.04.2014 12:58, schrieb Mauricio Tavares:
> On Mon, Apr 21, 2014 at 3:42 AM, Reindl Harald  wrote:
>>
>> Am 21.04.2014 03:39, schrieb Lars Seipel:
>>> Nicely aligning with the current firewall thread I noticed that one of
>>> my machines was running the exim MTA for the last few days, dutifully
>>> listening on all interfaces
>>
>> and now it is *proven for sure* that disable the firewall
>> by default is the most dumb thing a distribution can do
>>
>> drago01 will now say again "that is a bug"
>> yes, in that case in *two* packages at the same time
>> but hwat matters is the impact of a bug
>>
>> * smartmontools wanted sendmail instead MTA for sending sysmessages
>> * sendmail obviously has a braindead default configuration listening on all 
>> ports
>> * sendmail service is obviously enabled at install time even if smartmontools
>>   only need /usr/sbin/sendmail
>>
>> all things i said that they are happening and will happen again and again
>> while they get fixed here and there - again and again - that's life
>>
>> so you can run in circles and shout "that is a bug" which is
>> true and while you are fix it it brings people in trouble
>> or you have by default a security layer which hopefully does
>> not open port 25 automated because you install sendmail
>>
>> the next problem: even if such a bug is fixed the affected users
>> keep to be fucked because the updated smartmontools only require
>> any MTA (which is correct) and so nothing will remove sendmail
>> on that machines nor close port 25 after a update of smartmontools
>>
> If all smartmontools need is to just send emails out, I would
> suggest using something like ssmtp or msmtp

which needs configuration
local mail-pickup don't

and no i am not interested in discussions who reads that mails
serious users / admins do after they realized existence and
after that also the mails from the past

but you missed the point: because such things can happen a OS must
not be shipped with a disabled firewall these days - period



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 21.04.2014 11:13, schrieb drago01:
> On Mon, Apr 21, 2014 at 10:50 AM, Reindl Harald  
> wrote:
>> Am 21.04.2014 10:25, schrieb drago01:
>>> I did learn those things so did probably you and Harald but designing
>>> an operating system that requires deep technical understanding to be
>>> used is just a failure on our part
>>
>> you don't get it - ship dangerous defaults is just a failure on our part
>>
>> the user don't need to learn all the details
>> he needs only three choices
>>
>> * share for everyone inclduing the internt
>> * share only for the local network
>> * don't share for the network at all because it's used for plying on 
>> localhost
> 
> Yes we should provide those choices which is what I am saying making this
> choice should not (and does not) require the knowledge about networking nor
> how to configure the firewall.

you need at least to understand the difference between internet and a
local network to make this decision or chose "internet" needs to be
harder then "local network" to not open samba by accident

my *real* problem is that this dumb proposal "Disable firewall" is
still not rejected and whoever made it that way banned the next
12 months from making proposals affecting the whole distribution

> The tool that configures the sharing should do that for the user.  The
> user should not have to
> mess around with firewalls, network ports and interfaces himself.
> 
>> and while this *really* needed question is shown there should be
>> a link provided to read more about the differences
> 
>>> What seems easy and obvious to people on a *operating system
>>> development mailing list* is not for the general public (believe it or
>>> not that's a fact). And no that's not because
>>> people are stupid. They just have different professions and interests
>>
>> explain that to them after damage happened with "oh i thought we should
>> not bother you because we think you have different professions"
> 
> You missed the point again. Did you read the scientific papers I have
> pointed you at?

that scientific papers are self prophecy bullshit

if you often enough tell people they need not to know this and that
and later go out and ask them "are you interested in this and that"
what do you think will the answer be?








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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 21.04.2014 10:25, schrieb drago01:
> I did learn those things so did probably you and Harald but designing
> an operating system that requires deep technical understanding to be
> used is just a failure on our part

you don't get it - ship dangerous defaults is just a failure on our part

the user don't need to learn all the details
he needs only three choices

* share for everyone inclduing the internt
* share only for the local network
* don't share for the network at all because it's used for plying on localhost

and while this *really* needed question is shown there should be
a link provided to read more about the differences

> What seems easy and obvious to people on a *operating system
> development mailing list* is not for the general public (believe it or
> not that's a fact). And no that's not because
> people are stupid. They just have different professions and interests

explain that to them after damage happened with "oh i thought we should
not bother you because we think you have different professions"



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

an that is why we need a firewall -> Re: When a yum update sets up an MTA ...

[Reindl Harald]

Am 21.04.2014 03:39, schrieb Lars Seipel:
> Nicely aligning with the current firewall thread I noticed that one of
> my machines was running the exim MTA for the last few days, dutifully
> listening on all interfaces

and now it is *proven for sure* that disable the firewall
by default is the most dumb thing a distribution can do

drago01 will now say again "that is a bug"
yes, in that case in *two* packages at the same time
but hwat matters is the impact of a bug

* smartmontools wanted sendmail instead MTA for sending sysmessages
* sendmail obviously has a braindead default configuration listening on all 
ports
* sendmail service is obviously enabled at install time even if smartmontools
  only need /usr/sbin/sendmail

all things i said that they are happening and will happen again and again
while they get fixed here and there - again and again - that's life

so you can run in circles and shout "that is a bug" which is
true and while you are fix it it brings people in trouble
or you have by default a security layer which hopefully does
not open port 25 automated because you install sendmail

the next problem: even if such a bug is fixed the affected users
keep to be fucked because the updated smartmontools only require
any MTA (which is correct) and so nothing will remove sendmail
on that machines nor close port 25 after a update of smartmontools

https://koji.fedoraproject.org/koji/buildinfo?buildID=511458
* Thu Apr 17 2014 Michal Hlavinka 
 - 1:6.2-5 - require /usr/sbin/sendmail as MTA is not provided by all packages 
(#1048618)
* Tue Apr 15 2014 Michal Hlavinka 
 - 1:6.2-4 - use MTA instead of sendmail as a requirement (#1048614)
* Thu Apr 10 2014 Michal Hlavinka  - 1:6.2-3
 - add mail requires (#1048614)



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 21.04.2014 06:17, schrieb Orcan Ogetbil:
> On Sun, Apr 20, 2014 at 6:59 PM, drago01  wrote:
>> There is difference between a software developer, a sysadmin and a
>> user that simply wants to share his music with his family.  The latter
>> should not have to learn about computer security to do it,
> 
> Why not?
> 
> I lock my door every night before I go to sleep, because I learned
> about home security. I am neither a mayor nor a police officer.

well said! that's the attitude we need these days instead "things
are going bad each day but we give up and tell anybody he don't
need to learn anything about security"

in the world we live anybody REALLY NEEDS basic knowledge about
computer security or he will pay it sooner or later with his money
and/or lost data, that get's proven every week multiple times and
pretend the opposite has only two possibilities:

* maliciousness (fun about see the noobs falling)
* ignorance

from the viewpoint of a user falling sooner or later because
it was told to him he does not need to know it's maliciousness
and i would compare it with telling a blind man "you can go sir
the traffic lights are green" while they are red



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 21.04.2014 00:59, schrieb drago01:
> On Mon, Apr 21, 2014 at 12:39 AM, Reindl Harald  
> wrote:
> 
>>> There have been other suggestions in this thread that are helpful like
>>> the network zones thing (but we still have too many zones) or enabling
>>> services should make them work i.e
>>> just enable the firewall rules.
>>
>> which make sense
> 
> Oh finally you seem to understand what this is all about (a few mails
> ago this was supposed to be "strongly prohibited" ...)

if we talk about security business it is still wrong but somehow
acceptable - the problem you refuse to understand is that install
and start a service does not mean it should be reachable from the
network without confirmation

if somebody installs httpd on his developer workstation it does
not mean he wants to open the service for any machine but localhost
as example - the opposite is true because due development it's
most likely unsecure whatever runs there

> Now please goolge for "Psychological Acceptability and Security" you
> will find tons of scientific papers (read them) explaining about why
> it is wrong to silently break stuff or ask "yes / no" question or
> arguing with "this is not a blackbox the user should learn" nonsense.

that's not nonsense - that's the truth
you can accept that or put your head in the sand

at the end of the day any user pulling a network cable into his
machine or connect to a open WLAN will sooner or later get
troubles - the question is not if, the only question is how
much time it takes

> There is difference between a software developer, a sysadmin and a
> user that simply wants to share his music with his family

and since you don't know who is on front of a new installed
machine the defaults needs to be secure

> The latter should not have to learn about computer security to do it

i doubt he will be thankful for sharing his music to the whole
internet by default after he get jailed

> while for the former it does not matter that much as you said because
> they ought to know what to do or where to get that information from.

but they may make decisions based on "this distribution has insane
and insecure defaults, better take a different one"

> As for filling bugs because its broken even if it is not (obviously)
> exploitable because security mechanisms (firewall, selinux, nx, ...)
> are in place does not mean that we should not fix them

surely we should fix them

but your "because security mechanisms (firewall)" is pervert in a thread
with the subject "disable firewall"

for me personally that all as most of other Fedora decisions don't matter
because i get paied for secure networks and invent network wide defaults
with no care what the distributions ones are - but that's not the typical
users and that is why i refuse to understand such insane proposals like
"we don't know how to handle usability and firewall and so we disable
the firewall"



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 21.04.2014 00:22, schrieb drago01:
> On Mon, Apr 21, 2014 at 12:02 AM, Reindl Harald  
> wrote:
> 
>> * there are network services enabled by default
> 
> Again that's a bug and a viloation of the guidelines. Which services
> are you talking about?
> Please file bugs.

please stop to prove even more that you have no clue of security
a firewall and security layers are to prevent from *UNKNOWN* mistakes in the 
future
they are to prevent expose network services to the WAN which most likely are
intented for the local netwotk by the user (SMB and so on)

hope that the ISP is blocking incoming SMB connections from the WAN is not 
enough

* file bugs don't help in that context
* the damned ISO image don't get fixed
* even if it is replaced it takes way too long
* the already existing setups are insecure

"If you really know what you are doing you do *not* enable network
facing services without installing updates first" was honestly
enough to prove your missing understanding of the ordinary user
because the ordinary users install his OS and starts whatever
he wants to do with his computer - thinking that the first he
does before start network aware services is too seek for
security updates is laughable to say it in nice words

>> * avahi is one of them
> 
> You keep listing this as an example but avahi is not only installed
> and enabled by default
> but also allowed configured to work in the default firewall setup
> since F18 [1] ...

bad enough

> So the current default firewall won't protect you against avahi flaws.
> 
>> * you nor i can say for sure avahi never ever get a critical security update
> 
> See above.

see above

>> * you nor i can be sure that there is not another network-service is running
>> * even if it is not running by intention it may be running by mistake as 
>> default
>> * so after you installed a new system avahi is running and the firewall down
> 
> See above

there is nothing to read above

you don't understand what a "safe default" means
you even refuse try to understand it which is horrible in 2014

>> * how do you genius install the updates without a network
>> and to *not* have to consider what is safe and what you have to stop after
>> a fresh install before you can plug your machine to the network for install
>> security relevant updates a firewall has to be enabled by default
> 
> Again you
> 
> 1) assume that we enable random services by default and the firewall
> is the only thing that protects freshly installed systems
> 2) that given the user options that do not work and force him to learn
> about computer networks to do basic tasks is how things should work
> 
> both are false.

for you

not for people care about default security

> Sure disabling the firewall is not the only way to solve 2) but the
> "silently make things not work" i.e the status quo or "ask a user
> questions that he does not understand"
> are no solutions.

until you come up with better ones they are
disable the firewall is no solution

> There have been other suggestions in this thread that are helpful like
> the network zones thing (but we still have too many zones) or enabling
> services should make them work i.e
> just enable the firewall rules.

which make sense

your "if you are know what you are doing you don't" does not make sense
the user knowing whate he is doing don't need hand holding in any case

we are talking about terrible defaults

>> honestly it's good that you are out of this discussion because you seem
>> to not have you clue about security nor understand the implications of
>> "who knows hat he is doing and why the one who don't need sane defaults"
> 
> No the reason is simply that talking to you is very annoying

most of the time talking to people with a clue what they are talking about
is annoying - well, there are two choices. try to understand what they
are talking about or keep annoyed

> you resort to baseless attacks (like the this one) and strawmans.
> 
> 1: http://fedoraproject.org/wiki/Features/AvahiDefaultOnDesktop

well, maybe Avahi is a bad example because the major mistake in that
case already happened, but that's a weak excuse to make more wrong
decisions and throw the whole security of the distribution in a
default setup away



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 20.04.2014 23:44, schrieb drago01:
> On Sun, Apr 20, 2014 at 10:56 PM, Reindl Harald  
> wrote:
>> after you booted the new installed machine and open ports of
>> possible vulnerable services which needs updatdes it is
>> *too late* to enable the firewall for preventing already
>> happened damaged
> 
> Do you even know how backwards that reads?
> If you really know what you are doing you do *not* enable network
> facing services without installing updates first

I KNOW WHAT I AM DOING - THE POOR USER WITH INSECURE DEFAULTS DON'T

that is exactly the poor guy for wich the firewall should be disabled
in default installs to not overload his brain with a firewall

don't you realize how pervert your conclusion is?

> Anyway I am out of this discussion

you simply refuse to understand what i am saying

* there are network services enabled by default
* avahi is one of them
* you nor i can say for sure avahi never ever get a critical security update
* you nor i can be sure that there is not another network-service is running
* even if it is not running by intention it may be running by mistake as default
* so after you installed a new system avahi is running and the firewall down
* how do you genius install the updates without a network

and to *not* have to consider what is safe and what you have to stop after
a fresh install before you can plug your machine to the network for install
security relevant updates a firewall has to be enabled by default

honestly it's good that you are out of this discussion because you seem
to not have you clue about security nor understand the implications of
"who knows hat he is doing and why the one who don't need sane defaults"



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 20.04.2014 22:44, schrieb drago01:
> On Sun, Apr 20, 2014 at 10:15 PM, Reindl Harald  
> wrote:
>> Am 20.04.2014 20:19, schrieb drago01:
>>> On Sun, Apr 20, 2014 at 6:53 PM, Kevin Kofler  
>>> wrote:
>>>> Christian Schaller wrote:
>>>>> where we at the same time need to allow each user to have any port they
>>>>> desire opened for traffic to make sure things like DLNA or Chromecast
>>>>> works.
>>>>
>>>> Such things MUST NOT be enabled by default.
>>>
>>> No one suggested that. Currently the user enables them and they do not
>>> work until after he/she disables the firewall
>>
>> wrong - until he *configures* the firewall
> 
> If that knowledge is present sure

and disable it hence the knowledge is not there is the Apple way
do you really think the marekt share of linux will explode if
we provide unsecure defaults? i doubt

> If it isn't then either "this shit does not work" or the user will 
> somehow find out that it is caused by the firewall and try
> to disable it

or try to get the knowledge to configure it
in any case the user decides instead blame Fedora for the damaga
done with insecure defaults

>> to open the needed ports
>> if that can't be half-automated with confirmation in any case
>>
>> even open the ports full automated should be strongly prohibited
> 
> The user did chose to share data ... configure the firewall to allow
> it automatically
> should not be "strongly prohibited" because the user have chosen to
> share the data.
> Showing him information that the data would be shared to everyone on
> this network
> is fine but as soon as you go into implementation details and talk
> about ports you lost
> the user and he/she will just click "yes/ok/continue" ...

yes the user did click "share data"

and you really think he also meant "share data to the whole internet"?

>> because taking away the users control is *not* why Linux as
>> project was staretd
> 
> Again strawman .. its not about taking control from the user (you
> still can control the firewall settings)

you refuse to understand security basics

after you booted the new installed machine and open ports of
possible vulnerable services which needs updatdes it is
*too late* to enable the firewall for preventing already
happened damaged

> but let the computer do work in an automated way for the user i.e "why
> computers have been created"

*that* is a strawman

some people think computer needs to be that easy to
handle like a microwave - but the same people refuse
to understand that a computer is way more complex

don't you think there is a reason for get a driver license
before you are allowed to enter a public street?

>> i doubt that *any* software on this planet needs the firewall to be
>> completly disbaled and if such crap was written because using random
>> ports for no good reason it has no existence authority
> 
> No it does indeed not *need* to be completely disabled but apps should
> not open random ports without any reason to begin with
> (we should not ship those and we have a rule to not enable network
> facing services by default despite of the firewall)

but this damned proposal is about *completly disable it*

did you read the OP?
did you try to understand it?

in simple words it means "because we are currently unsure
how to provide secure defaults while not block enabled
services we give up and throw away security at all because
we prefer anything working out of the box without minimal
understanding of the user what he is doing over security"

than just install one of the already available by default
unsecure operating systems instead damage Linux and bring
it in the same bad shape - there are enough Linux users
which chosed the OS because it's by default configured in
a secure way and that is what users expect in 2014



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 20.04.2014 20:19, schrieb drago01:
> On Sun, Apr 20, 2014 at 6:53 PM, Kevin Kofler  wrote:
>> Christian Schaller wrote:
>>> where we at the same time need to allow each user to have any port they
>>> desire opened for traffic to make sure things like DLNA or Chromecast
>>> works.
>>
>> Such things MUST NOT be enabled by default.
> 
> No one suggested that. Currently the user enables them and they do not
> work until after he/she disables the firewall

wrong - until he *configures* the firewall to open the needed ports
if that can't be half-automated with confirmation in any case

even open the ports full automated should be strongly prohibited
because taking away the users control is *not* why Linux as
project was staretd - there are enough other blackbox systems

i doubt that *any* software on this planet needs the firewall to be
completly disbaled and if such crap was written because using random
ports for no good reason it has no existence authority

there is *no single* valid reason to disable the firewall as default
in 2014 period and if there are applications which needs manual
configuration from the user then lead him to the needed documentation
or remove that completly from the distribution

anybody thinking in 2014 install a OS with a disabled firewall must
have lived below a stone the last decade and should not be permitted
to make decisions affecting the enduser

and honestly the above was said as nice as possible, maybe even too nice



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 17.04.2014 18:26, schrieb Paul Wouters:
> On Thu, 17 Apr 2014, Daniel J Walsh wrote:
> 
>> Didn't mean to accuse you of saying that.  I do like the idea of asking
>> if you are on a "trusted" network.
> 
> For DNS issues we have similar issues. A sane default seems to be that
> if you plugin a cable or you enter wifi WPA(2) details, you are
> trusting the network you are connecting to per default. (with NM
> override options for corner cases like using WPA2 on your phone as
> hotspot but you don't trust the telco network)

by plugin a cable you trust the network?
seriously?

you may live in a world with only wireless clients and that's why
plugin a cable is something special that it only happens at your
home network - i can tell for sure that's not really true

you have to be *asked* if you trust that network and no i do
not buy the argumentation "the user anyways says yes" because
even don't ask shoots also the one which would think about or
say "no" for good reasons





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: libreoffice broken again in updates-testing

[Reindl Harald]

Am 17.04.2014 16:19, schrieb Reindl Harald:
> Am 17.04.2014 16:16, schrieb Sérgio Basto:
>> I don't broken deps [1] , the important is why you got broken deps 
>>
>> [1] yum  --enablerepo=updates-testing update --advisory FEDORA-2014-5062
>>
>> I'm installing libreoffice-4.2.3.3-4, and you are installing
>> libreoffice-4.2.3.3-3, so that is the problem, you need refresh yours
>> yum cache 
> 
> if you would have followed the thread you would have seen the below:
> 
> i did *multiple* rm -rf /var/cache/yum/* all day long as also statet on bodhi
> like a wonder this morning the update was pushed, see also the other comment
> on bodhi about the not pushed 4.2.3.3-4
> 
> the broken one should have been unpushed anyways

and before you tell me now about outdated mirrors - no, see repo-file below
what you are installing *now* don't matter, *now* 4.2.3.3-4 is in the repo
starting with tuesday evening until today the broken one was

to make it short: i can handle yum and repos

[root@rh:~]$ cat /etc/yum.repos.d/fedora-updates.repo
[updates]
name=Fedora $releasever - $basearch - Updates
failovermethod=priority
baseurl=https://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch



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: libreoffice broken again in updates-testing

[Reindl Harald]

Am 17.04.2014 16:16, schrieb Sérgio Basto:
> On Qui, 2014-04-17 at 00:48 +0200, Reindl Harald wrote: 
>> why do whe have that always with libreoffice?
>> the broken build hangs around for 30 hours in the repo
>> the supposed to fix that one is not pushed
>> even with using the koji-repo no way t osolve that
>>
>> https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20?_csrf_token=05a8ab02f2593f3e95b04291696587c8234d903a
>>
>> Error: Package: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 (updates-testing)
>>Requires: libxmlsecurity.so()(64bit)
>>Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 
>> (@updates-testing)
>>libxmlsecurity.so()(64bit)
>>Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
>> (updates-testing)
>>Not found
>>Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
>>libxmlsecurity.so()(64bit)
>> Error: Package: 1:libreoffice-calc-4.2.3.3-3.fc20.x86_64 (updates-testing)
>>Requires: libcomphelper.so()(64bit)
>>Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 
>> (@updates-testing)
>>libcomphelper.so()(64bit)
>>Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
>> (updates-testing)
>>Not found
>>Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
>>libcomphelper.so()(64bit)
> 
> I don't broken deps [1] , the important is why you got broken deps 
> 
> [1] yum  --enablerepo=updates-testing update --advisory FEDORA-2014-5062
> 
> I'm installing libreoffice-4.2.3.3-4, and you are installing
> libreoffice-4.2.3.3-3, so that is the problem, you need refresh yours
> yum cache 

if you would have followed the thread you would have seen the below:

i did *multiple* rm -rf /var/cache/yum/* all day long as also statet on bodhi
like a wonder this morning the update was pushed, see also the other comment
on bodhi about the not pushed 4.2.3.3-4

the broken one should have been unpushed anyways




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: libreoffice broken again in updates-testing

[Reindl Harald]

Am 17.04.2014 09:50, schrieb David Tardon:
> On Thu, Apr 17, 2014 at 12:48:47AM +0200, Reindl Harald wrote:
>> why do whe have that always with libreoffice?
> 
> I will send a note to the editors of Oxford English Dictionary that
> "always" has been redefined to mean "in less than 10 % of cases". If I
> count correctly, we have issued 26 updates for F-20 that made it into
> stable (plus a few others that were obsoleted by a later one). One of
> these had a problem. Now there is a second one.

the main question is why

>> the broken build hangs around for 30 hours in the repo
> 
> Good. Since you are so concerned about it, what have you done to make me
> aware of the problem? 

https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20?_csrf_token=18bde034162ac31ef2045718cb3349921b85b388

 hreindl - 2014-04-16 09:02:37
independent of how often i do rm -rf /var/cache/yum* i still have the broken 
previous build in updates-testing
starting with yesterday evening Processing Dependency: libtllo.so()(64bit) for 
package:
1:libreoffice-writer-4.2.3.3-3.fc20.x86_64

> Hint: I consider the mails from various Fedora tools as nonessential

which seemes to be a problem if you don't verify your builds

> to be read when I have time. But there are other ways, more suitable 
> for urgent problems, like IRC...

well you could simply try updates-testing at your own

> Btw, 30 hours is not so much, considering that it takes f*ing 14 hours
> just to build new packages because of ARM...

the 30 hours starts couting *after* that and has to be added

>> the supposed to fix that one is not pushed
> 
> https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20
> got +2 karma and passed AutoQA. Whatever has happened after that is
> hardly my fault.

i don't care who's fault it is - that build does not help as long the
previous made it already in a repo




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

libreoffice broken again in updates-testing

[Reindl Harald]

why do whe have that always with libreoffice?
the broken build hangs around for 30 hours in the repo
the supposed to fix that one is not pushed
even with using the koji-repo no way t osolve that

https://admin.fedoraproject.org/updates/FEDORA-2014-5062/libreoffice-4.2.3.3-4.fc20?_csrf_token=05a8ab02f2593f3e95b04291696587c8234d903a

Error: Package: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 (updates-testing)
   Requires: libxmlsecurity.so()(64bit)
   Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 (@updates-testing)
   libxmlsecurity.so()(64bit)
   Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
(updates-testing)
   Not found
   Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
   libxmlsecurity.so()(64bit)
Error: Package: 1:libreoffice-calc-4.2.3.3-3.fc20.x86_64 (updates-testing)
   Requires: libcomphelper.so()(64bit)
   Removing: 1:libreoffice-core-4.2.3.3-1.fc20.x86_64 (@updates-testing)
   libcomphelper.so()(64bit)
   Updated By: 1:libreoffice-core-4.2.3.3-3.fc20.x86_64 
(updates-testing)
   Not found
   Available: 1:libreoffice-core-4.1.3.2-9.fc20.x86_64 (fedora)
   libcomphelper.so()(64bit)



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 22:19, schrieb Andreas Tunek:
> 2014-04-15 21:28 GMT+02:00 Reindl Harald :
>>
>>
>> Am 15.04.2014 20:18, schrieb Andreas Tunek:
>>> 2014-04-15 20:08 GMT+02:00 Reindl Harald :
>>>> Am 15.04.2014 20:03, schrieb Andreas Tunek:
>>>>> I just want to say that I really support this feature. I do not see
>>>>> any point in a firewall for a "Workstation".
>>>>
>>>> that's obviously
>>>>
>>>>> BTW, while we are on the subject, does anyone know how to actually
>>>>> disable the firewall in Fedora 20? I haven't managed to figure it
>>>>> out
>>>>
>>>> and that is why you like it to be disabled for anybody?
>>>>
>>>> https://www.google.com/search?q=fedora+20+disable+firewall
>>>> https://fedoraproject.org/wiki/FirewallD
>>>>
>>>> as for any other service:
>>>> systemctl disable firewalld.service iptables.service
>>>> systemctl stop firewalld.service iptables.service
>>>
>>> If you look here it says you only have to disable firewalld:
>>> http://forums.fedoraforum.org/showthread.php?t=296398
>>>
>>> Do you actually have to disable iptables as well?
>>
>> what are you doing in that thread?
> 
> That thread was the second result from the google search you made a
> link to. I assume you posted that link for a reason.

this is a development list, i posted that link because normally
someone types "Fedora disable firewall" in Google, my question
was more meant why do you discuss on a technical list inside
security related topic if you miss basics

>> if you don't know how to disable a service you have not
>> any qualification to discuss here about security and that
>> words are as friendly chosen as possible!
>>
>> type the two commands i posted and be happy
> 
> I am more happy when I learn about how stuff actually works.

fine *but* that thread is *not* the right place

i even go so far to say you do *not* need nor *should*
you disable your firewall, you should learn how to
open ports and which one you are *really* need to
be opened instead throw away any security barrier
beause it is so much easier not close the door and
hope after coming home your TV is still there

>> i don't know if oyu are using the classic iptables service or
>> firewalld nor am i interested and so i told you a command to
>> disable and stop both  - no idea why you need to answer with
>> a forum thread which i don't care at all
> 
> If you are not interested you can just ignore posts

that's not the point

the point is that you discuss in a security related topic
while your problem is far off-topic

> But anyway, wasn't it quite clear that I am running 
> the default Fedora 20 setup?

no, there is nothing quite clear because we talk about a
linux system which may have seen dist-upgrades from times
before firewalld even existed (like all my systems) or
highly customized and *because* of that i posted a command
to disable *both* possibilities *additionally* to show how
find such informations at your own




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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 20:18, schrieb Andreas Tunek:
> 2014-04-15 20:08 GMT+02:00 Reindl Harald :
>> Am 15.04.2014 20:03, schrieb Andreas Tunek:
>>> I just want to say that I really support this feature. I do not see
>>> any point in a firewall for a "Workstation".
>>
>> that's obviously
>>
>>> BTW, while we are on the subject, does anyone know how to actually
>>> disable the firewall in Fedora 20? I haven't managed to figure it
>>> out
>>
>> and that is why you like it to be disabled for anybody?
>>
>> https://www.google.com/search?q=fedora+20+disable+firewall
>> https://fedoraproject.org/wiki/FirewallD
>>
>> as for any other service:
>> systemctl disable firewalld.service iptables.service
>> systemctl stop firewalld.service iptables.service
> 
> If you look here it says you only have to disable firewalld:
> http://forums.fedoraforum.org/showthread.php?t=296398
> 
> Do you actually have to disable iptables as well?

what are you doing in that thread?

if you don't know how to disable a service you have not
any qualification to discuss here about security and that
words are as friendly chosen as possible!

type the two commands i posted and be happy

i don't know if oyu are using the classic iptables service or
firewalld nor am i interested and so i told you a command to
disable and stop both  - no idea why you need to answer with
a forum thread which i don't care at all



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 20:03, schrieb Andreas Tunek:
> I just want to say that I really support this feature. I do not see
> any point in a firewall for a "Workstation".

that's obviously

> BTW, while we are on the subject, does anyone know how to actually
> disable the firewall in Fedora 20? I haven't managed to figure it
> out

and that is why you like it to be disabled for anybody?

https://www.google.com/search?q=fedora+20+disable+firewall
https://fedoraproject.org/wiki/FirewallD

as for any other service:
systemctl disable firewalld.service iptables.service
systemctl stop firewalld.service iptables.service



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 19:05, schrieb Andrew Lutomirski:
> On Tue, Apr 15, 2014 at 10:00 AM, Reindl Harald  
> wrote:
>> Am 15.04.2014 18:51, schrieb Andrew Lutomirski:
>>> On Tue, Apr 15, 2014 at 9:44 AM, Reindl Harald  
>>> wrote:
>>>>
>>>>
>>>> Am 15.04.2014 17:40, schrieb Andrew Lutomirski:
>>>>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald  
>>>>> wrote:
>>>>
>>>>> How about having an API where things like DLNA can simply
>>>>> not run until you're connected to your home network?
>>>>
>>>> you can prove that this will always happen the right way?
>>>> you can implement software *for sure* knowing the fact
>>>> what my home network is? if you can do that you get rich!
>>>
>>> Does the firewall really help?
>>
>> yes, because there is no single port reachable after the
>> installation and you can at least install security updates
>> released after the GA of the current Fedora setup until
>> you have a port open
> 
> This is true even without the firewall.  I'd argue that one of the
> Workstation release requirements should be that a default installation
> opens no ports to the outside world

and i argue that this does *not* help in case of a later happening
bug after an update nor if you install any application later
opening ports not intended for the WAN and you are not aware of
the missing firewall because nobody right in his mind assumes
that in 2014 a operating system comes out with dsiabled packet
filters

what you propose is hope and pray
security don't work that way

security can only work if one single bug somewhere does not lead
to a disaster because nobody looked at the whole picture and
assumed all is working as intended

it is *proven* that this does not work and it is *really*
scary that we have to discuss that in the year 2014 and
especially one weak after Heartbleed

WTF do somebody proposing to disable the firewall imagine would have
happened if there has been a *highly secure application, allowing
connections only with a matching SSL cert and using OpenSSL would have
faced the public internet last week*

why do people not realize what *big difference* between opening that
port only *willingly* to the WAN because playing locally with that
application and have it open by default would have made?

and guess what: exactly the people with no clue about security and
how to take care are the ones *not able* to turn on shields because
they don't ask for it - if something don't work because the shields
these people asking usually or better leave the shields up



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 18:51, schrieb Andrew Lutomirski:
> On Tue, Apr 15, 2014 at 9:44 AM, Reindl Harald  wrote:
>>
>>
>> Am 15.04.2014 17:40, schrieb Andrew Lutomirski:
>>> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald  
>>> wrote:
>>
>>
>>> How about having an API where things like DLNA can simply
>>> not run until you're connected to your home network?
>>
>> you can prove that this will always happen the right way?
>> you can implement software *for sure* knowing the fact
>> what my home network is? if you can do that you get rich!
> 
> Does the firewall really help?  

yes, because there is no single port reachable after the
installation and you can at least install security updates
released after the GA of the current Fedora setup until
you have a port open

> Why should you trust your home network anyway?  

because i get paied for secure comapny networks?

> Your already-known-to-be-malicious television can mess with
> ARP or DHCP, intercept an HTTP request, and CSRF the crap 
> running on your computer.

my television can do a CRSF?
my television can send me a mail and click on a link there?

don't talk about things which are *obviously* out of your business
http://en.wikipedia.org/wiki/Cross-site_request_forgery

and no my television can do nothing because my television is blocked
on any incoming port on my computer - guess by what: the firewall

> Note that there are two separate issues there.  Your home network is
> *not* secure, and your firewall, even in fully locked-down mode, isn't
> really protecting you

in other words: let us give up with security, disable any barrier
and security layer because we can't win that fight - interesting
attitude!



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 18:38, schrieb Mateusz Marzantowicz:
> On 15.04.2014 11:40, Reindl Harald wrote:
>>
>> it is not a point of *what i can do and do*
>> it is a point what the ordinary 08/15 user does which assumes
>> to have a by default secure system after install
> 
> Fedora is not for ordinary users. Fedora is for geeks and 
> developers that like to experiment with a new software

ok, now i need hardly to censor myself

may i ask you to be quiet until you read and understand the
proposal linked in the start-message of that thread as well
as the target audience for "Fedora Workstation"?

the whole point of that thread and the Workstation prodcut
is to satisfy the ordinary user and let nor firewall stand
in his way

if it would be only for geeks or developers they would
simply open the needed ports and knwoing what they are
doing - they don't need firewalld

> Ordinary users use Windows and iOS (sometimes RHEL)

which is better for them if we start to ship
Fedora with

> Averedge Fedora user should be able to enable/disable firewall

*then this thread would not exist and it would still be enabled*

> and justify if he needs such thing. So this decision about disabling 
> fw be default is complitelly not important from security point of 
> view. You can alway drop some iptables rules to your rc.local script

STOP THAT: if you setup a fresh install and your machine is in
a untrustable network or directly connected to the WAN you have
no chance to enable the firewall from the moment on one of the
by default started services like Avahi has a critical bug
nobody oculd have imagined before and you are fucked due the
first boot as it happened to WinXP in the past

do we really want to enter that road to hell?




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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 18:13, schrieb Andrew Lutomirski:
> On Tue, Apr 15, 2014 at 9:04 AM, Christopher  wrote:
>> Ideally, users would have complete knowledge of the behavior of every
>> piece of software in their system that utilizes the network, in which
>> case, they could very easily get by without a firewall. However, that
>> is not a reasonable expectation. A firewall protects users with
>> incomplete knowledge of their software.
>>
>> Example: user installs software X... but oops, they didn't realize it
>> was going to listen on port Y but that's okay, because no firewall
>> rule has been enabled to allow traffic on port Y, so the user is
>> secure.
> 
> This sounds like a problem that should be separately fixed

please stop to talk about security because your argumentation
shows that you are clueless at this topic - you can't fix
all problems in every application

damend it is enough to have a sane and secure application
listening on a public reachable port after a until now
unknown security flaw was found, in the worst case combined
with privilege escalation





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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 17:40, schrieb Andrew Lutomirski:
> On Tue, Apr 15, 2014 at 7:42 AM, Reindl Harald  wrote:

>> that is pretty easy - defaults have to be closed anything and the user
>> have to make a choice for, otherwise if there are cirtical security
>> updates after a release you have *exactly* the same as WinXP SP2
> 
> WinXP SP2 needed a firewall because MS didn't want to close ports 139
> and 445 for real.  

because it is used for filesharing - period

> So instead they hacked it up with a firewall.  This
> meant that, if you had the firewall blocking those ports, you were
> okay, but if they were open (e.g. because you were at home), you were
> screwed.
> 
> This is *not* a good thing.

and the same happens with the Fedora Workstation argumentation
for whatever service

> Can someone explain what threat is effectively mitigated by a firewall
> on a workstation machine?  Here are some bad answers:
> 
>  - Being pwned via MS's notoriously insecure SMB stack?  Not actually
> a problem for Fedora.

stop that argumentation

you *never* can prove that for a predictable future
you *never* can prove that now

why?

* because you don't know what the user is running
* you don't know about security bugs now or in the furture


>  - DLNA / Chromecast / whatever: wouldn't it be a lot more sensible
> for these things to be off until specifically requested?

yes

but you can't relie on that if we talk about security


> How about having an API where things like DLNA can simply 
> not run until you're connected to your home network?

you can prove that this will always happen the right way?
you can implement software *for sure* knowing the fact
what my home network is? if you can do that you get rich!

> Also, having a firewall on exposes you to a huge attack surface in
> iptables, and it doesn't protect against attacks targeting the
> kernel's IP stack

fine - and because you can't reach 100% security you disable
an important security layer? well, than let us remove any
security barrier and give up because you will never reach
the 100% - not now, not tomorrow and not in 100 years

> I'm all for "secure by default", but I'm not at all convinced that
> current desktop firewalls add any real security

there is no "real security" on that planet
everybody working in the security business will explain that to you

you can refuse and ignore the facts, but they are still facts



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 16:28, schrieb Christian Schaller:
> - Original Message -
>> From: "Reindl Harald" 
>> To: devel@lists.fedoraproject.org
>> Sent: Tuesday, April 15, 2014 11:40:20 AM
>> Subject: Re: F21 System Wide Change: Workstation: Disable firewall
>>
>>
>> Am 15.04.2014 11:32, schrieb drago01:
>>> On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald 
>>> wrote:
> 
>> allow any random application to open a unprivlieged
>> port which is reachable from outside is dangerous
>>
> We already allow that and have for a long while. Any application bothering to 
> support 
> the firewalld dbus interface can open any port they wish to.

that is bad enough *but now* we disable any firewall at all?
seriously?

> There was a long thread about this on the desktop mailing list, and I was 
> not in the 'disable the firewall' camp in that discussion, but nobody in 
> that thread or here have articulated how the firewall exactly enhance 
> security 
> in the situation where we at the same time need to allow each user to have 
> any 
> port they desire opened for traffic to make sure things like DLNA or 
> Chromecast 
> works.

that is pretty easy - defaults have to be closed anything and the user
have to make a choice for, otherwise if there are cirtical security
updates after a release you have *exactly* the same as WinXP SP2

try it out on a public reachable IP, you will not survive the time
you need to apply the security updates because you are infected
long before

honestly if these days i would consider switch to linux and unsure
which distribution the one proposing "disable firewall by default"
would be the last one on the list



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 15:59, schrieb Michael Catanzaro:
> On Tue, 2014-04-15 at 14:35 +0200, Zbigniew Jędrzejewski-Szmek wrote:
>> What needs to be done to improve the firewall integration?
>>
>> Zbyszek
> 
> The rule in the Workstation technical spec is: "A firewall in its
> default configuration may not interfere with the normal operation of
> programs installed by default." [1] There's a discussion on the desktop
> list beginning at [2] that has some brainstorming and explanation as to
> why this would be hard.
> 
> [1]
> https://fedoraproject.org/wiki/Workstation/Technical_Specification#Firewall
> 
> [2]
> https://lists.fedoraproject.org/pipermail/desktop/2014-February/009142.html

that is all fine, but throw away security because it stands
in the way of comfort is a terrible step - security *always*
will affect usability - you can't have both perfect, never

but if you drop security for usability in 2014 after the last
3 years clearly showed that any application and library out
there was multiple vulerable in unexpected ways you will not
do a favour to your users and the possible damage to the
project if it comes to mass security flaws in "Fedora Workstation"
setups a few months after it's first release can never be repaired

if i say never then i mean never

having press articles with "this and that happened because they
dropped the firewall for more comfort" leaves a bad taste for
the future - and not only for the Workstation, also for other
products and the distribution because it is a hint for a general
attitude that security no longer counts - frankly that can even
damage other distributions "Linux goes the same way of unsecure
defaults"



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 11:32, schrieb drago01:
>> do "we" really want to go the way of dangerous defaults without
> 
> ... "dangerous" ?
> 
> So install the workstation package set. Boot it up. Disable the firewall.
> Which kind of vulnerabilities are able to find? Which ports are
> accessible? 

Avahi at least

> What can you do with them?

that will the time tell you after there where security flaws nobody
expected before when it is too late - it is somehow pervert to
argue that way and make proposals to weaken the default security
exactly one week after "Heartbleed"

"what can you do with them" if it comes to security is the wrong
question - what can you not do with them and how do you prove
that would be the right question

not a single security flaw in the past yeas was expected and
now instead learn of them we disable security layers?

short ago it was proposed "drop tcpwrapper from the distribution
because there is a firewall and we should rely on a sinle layer
of defense" followed directly by "oh and now let us disable that
security layer in a default install"

to make it clear: myself is not affected by such things but it
scares me because i have to fight as server-admin with the
impact of dumb security decisions and the resulting botnets

and yes you have to be very careful with "but we are not vulerable
like this and that" because that's the first step to fall hard



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 11:32, schrieb drago01:
> On Tue, Apr 15, 2014 at 11:18 AM, Reindl Harald  
> wrote:
>>>> User Experience
>>>> Applications that are using sharing protocols such as DAAP or
>>>> UPnP will work out of the box, without the need to tweak or
>>>> disable the firewall service
>>
>> seriously going the Apple way and back to where WiNXP before SP3 was?
> 
> strawman

no it's a fact, before SP3 WinXP had no firewall and MS learned

>> users running applications which opening a high port in the background
>> like license checks and so on (as example ZendStudio) will be really
>> thankful that as default these ports are open on the WAN
> 
> Why does it listen on a port for license checks? It should just
> contact the server and not the other way.

it's hardly your business nor mine, fact is that you as os-vendor
can not know what application is opening whatever ports and thats
why you have to ship secure defaults

> Besides no one is stopping you from enabling the firewall

did you really not learn anything from the past 10 years like
new Windows setups where infected before you even had the
chance to install the security updates or enable a firewall?

it is not a point of *what i can do and do*
it is a point what the ordinary 08/15 user does which assumes
to have a by default secure system after install

>> honestly whoever proposes such a change has to understand that these
>> days it is not uncommon to have diretly to the WAN exposed machines
>> with no safety NAT/router between (UMTS/3G sticks, untrusted WLAN)
>> independent of whatever product a new installed system has not
>> to open any port by default
> 
> I agree to that but the point is "open by default". But if the user
> chooses to open it it share a file or whatever it should "just work".
> 
>> - anybody proposing the opposite
>> is careless and ignorant if it comes to security
> 
>> do "we" really want to go the way of dangerous defaults without
> 
> ... "dangerous" ?

allow any random application to open a unprivlieged
port which is reachable from outside is dangerous

> So install the workstation package set. Boot it up. Disable the firewall.
> Which kind of vulnerabilities are able to find? Which ports are
> accessible? What can you do with them?

*we talk about a operating system*

there is installed software later
i do not know and you do not know what is running on the users machine

>> at least two buttons "secure defaults" and "i don't care" due
>> the installation?
> 
> No that's dumb

dumb is "we can't handle security currently in a default install and
so we disable it completly" with other words like "we will disable
the firewall service while we are working on a more user-friendly way
to deal with network-related privacy issues"



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

Re: F21 System Wide Change: Workstation: Disable firewall

[Reindl Harald]

Am 15.04.2014 11:01, schrieb Jaroslav Reznik:
> = Proposed System Wide Change: Workstation: Disable firewall = 
> https://fedoraproject.org/wiki/Changes/Workstation_Disable_Firewall
> 
> Change owner(s): Matthias Clasen 
> 
> The firewalld service will not be enabled by default in the workstation 
> product. 
> 
> == Detailed Description ==
> The current level of integration into the desktop and applications does not 
> justify enabling the firewalld service by default. Additionally, the set of 
> zones that we currently expose is excessive and not user-friendly. Therefore, 
> we will disable the firewall service while we are working on a more user-
> friendly way to deal with network-related privacy issues.
> 
> It will of course still be possible to enable the firewall manually. 
> 
> == Scope ==
> * Proposal owners/Other developers: Add a Workstation-specific service 
> configuration (preset ?) to the firewalld package that disables firewalld for 
> the Workstation product 
> * Release engineering: No action required 
> * Policies and guidelines: No action required 

>> User Experience
>> Applications that are using sharing protocols such as DAAP or
>> UPnP will work out of the box, without the need to tweak or
>> disable the firewall service

seriously going the Apple way and back to where WiNXP before SP3 was?
users running applications which opening a high port in the background
like license checks and so on (as example ZendStudio) will be really
thankful that as default these ports are open on the WAN

honestly whoever proposes such a change has to understand that these
days it is not uncommon to have diretly to the WAN exposed machines
with no safety NAT/router between (UMTS/3G sticks, untrusted WLAN)

independent of whatever product a new installed system has not
to open any port by default - anybody proposing the opposite
is careless and ignorant if it comes to security

do "we" really want to go the way of dangerous defaults without
at least two buttons "secure defaults" and "i don't care" due
the installation?



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: default local DNS caching name server

[Reindl Harald]

Am 13.04.2014 08:42, schrieb Simo Sorce:
 * DNS cache should be flushed on route or interface state change.
> 
> I do not see why, the only reason to flush a cache is when there is a
> DNS change (new interface, eg VPN coming up, or going away)

because if i change my routing from ISP to VPN i want to access
the company severs over the VPN - any of them

changing the default root is a common way for such a switch

>> the cache already is running in my LAN for good reasons
> 
> That's a different cache, however if you feel strongly you will be able
> to turn off the local caching dns server on your machines, at your
> option.
> 
>> that DNS cache is pushed with DHCP
> 
> Forwarders are pushed via DHCP, not caches

says who?
you or better the one built the network and services?

the via DHCP pushed DNS servers are caches because they do not forward
anything, they are doing recursion - if youre DNS servers are only
forwarders consider to change that

frankly the main reason i stepped in that thread at all is that
people started to talk about recursion / forwarding without
understand that both terms in case of DNS

>> that DNS cache already does DNSSEC validation
> 
> Which is useless in the *general* case. You may think your physical
> security is perfect, that;s great, but for everybody else, trusting the
> network is not ok, that's why more an more people de[ploy TLS or GSSAPI
> in internal networks too.
> The era of the clear text trusted private network is coming to an end,
> whether you like it or not.
> 
>> if you don't trust the network itself you are lost anyways
> 
> Let me troll a bit, this is why you do all your banking without
> HTTPS ? :-)

that is a completly different story, you enter a HTTPS URL manually
or triggered by HSTS, so you request a encrypted connection from
the very first start

in case of DNS there is nothing encrypted at start resolving
and if i proper manipulate the network you are in i hide any
DNSSEC response from you (deep packet inspection)

> I am strongly in favor of a DNS cache on Fedora, and I would even
> seriously consider any proposal of making it the default on Fedora
> Server too

as long as it is not a hard wired dependency.
i don't need additional DNS servers on any system

the systems are running BIND are doing that with good reasons
the systems running Unbound as local cache doing that for good reasons (MTA 
servers)
the systems running dnsmasq are doing it for good reasons (Reverse-proxy with 
own DNS view)



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: default local DNS caching name server

[Reindl Harald]

Am 13.04.2014 03:07, schrieb Paul Wouters:
> On Sun, 13 Apr 2014, William Brown wrote:
>> When they change records in their local zones, they don't want
>> to have to flush caches etc. If their ISP is unreliable, or their own
>> DNS is unreliable, a DNS cache will potentially mask this issue delaying
>> them from noticing / solving the problem.
> 
> This is becoming really contrived. Again, if you think this is a real
> scenario (I don't think it is) than you could run unbound with ttl=0

i would run BIND and not unbound in any case
and now?
would you pull me unbound as dependency?

> But a requirement of automagically understanding what a local zone is
> and automagically understanding when a remote authoritative dns server
> changes data, and not willing to enforce that with ttl=0, and using
> that as argument why any solution of unbound to provide a security
> feature (DNSSEC) is getting a little unrealistic. If you want your
> laptop to start validating TLSA and SSHP and OPENPGPKEY records, you
> need DNSSEC validation on the device. The question should be "how do you
> change your network requirements to meet that goal". Yes, enforcing
> security comes at a price.

boah it is *not* a security feature having a local resolver
which may bypass my DHCP provided DNS which may be the only
one with the correct DNS view

if you ask him anyways the result can't be more secure than
aksing him directly, if not your breaking real world

in other words: if you are in a untrustable LAN you can not
make it more trustable without good changes to break things
in trustable ones

> Let me use your scenario based on TLS. You want to be able to change
> your TLS certificates and the private CA you regenerate at any time,
> without any browser on your network ever giving you a popup warning.
> You know you cannot ask this - it goes against the security model. The
> same applies for DNS with DNSSEC. The security demands we need to do
> validation and caching and we should try to make that as flexible and
> painless as possible

uhm no - there is a CA
signed root zone -> signed TLD -> signed domain

and if you believe that in a not trustable network you don't
know if you get the signing informations at all - fine, but
you hardly an enforce that with a local software

if i control the network i control the whle traffic and without
your own satellite link you can't change that

>> Case 4, 5, 6 and 7: DNS cache, again, isn't needed.
> 
> Again, DNSSEC validation on the device requires caching.

the question is if i gain aynthing doing it on the end-device

>> The infrastructure
>> is well setup, and caching is done by the business servers. DNS outages
>> at the business level, mean there are other issues and they will likely
>> be resolved quickly. You don't want to reboot / reset interfaces for
>> each time you make a change or as the first result of an issue (Again,
>> this would give fedora a bad name). DNS caching may mask a bigger
>> problem.
> 
> I don't really understand this paragraph.

have fun debugging DNS troubles of a road-warrior in your network
without realize that he brings his own DNS server

>> In conclusion, I don't percieve that a DNS cache in Fedora is a good
>> idea, as it solves few real world problems, and may in fact create
>> issues, mask issues and create a bad stigma about Fedora network
>> reliability. If it is to become available to users I would like:
> 
> I believe you will need to re-think that in light of running a
> validating DNSSEC resolver on your laptop or servers.

no

>> * DNS cache is not the default. It bust be enabled on a connection (IE
>> user's in case 1 can enable it if needed)
>> * DNS cache should be able to be enabled from the NM Gui
>> * DNS cache should be able to be flushed live from the NM Gui
>> * DNS cache should be flushed on route or interface state change.
>> * If two interfaces are active, the default route DNS cache setting
>> takes precedence.
> 
> You cannot separate dns cache from DNSSEC. DNS caching is not a problem,
> it is a feature. If you don't want your records cached, use ttl=0

the cache already is running in my LAN for good reasons
that DNS cache is pushed with DHCP
that DNS cache already does DNSSEC validation

if you don't trust the network itself you are lost anyways



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: default local DNS caching name server

[Reindl Harald]

Am 12.04.2014 17:21, schrieb Paul Wouters:
> On Sat, 12 Apr 2014, Reindl Harald wrote:
> 
>>> That's wrong. a DNS server can use a forwareder for some or all of its
>>> recursive queries. unbound+dnssec-triggerd mostly cause unbound to do
>>> full recursion but using the ISP nameserver as forward for all queries.
>>
>> oh no - please try to understand what recursion means in case of DNS
>>
>> may i suggest to read some docs because if i talk about DNS as one
>> who maintains 600 domains as DNS provider as well as Registry for
>> the .at domain and implemented DNS admin-backends years ago i know
>> what i am talking about
> 
> If we are going to do appeals to authority for making arguments, I've
> been doing DNSSEC since 2001, ran an ISP between 1995 and 2005 that had
> 500+ domains, have pending DNS RFC drafts out there, am acknowledged
> on many more DNS RFCs published, am a member of a global DNS incident
> response team, member of DNS-OARC, implemented a failover dual-software
> dual-setup multi-local DNSSEC signed for a TLD larger that .at praised
> by the entire DNS industry, performed DNS outage post-mortem at one of
> Canada's largest banks and was one of ten ICANN newGTLD Registry Services
> panel members evaluting the 1500 new TLD submissions for their technical
> implementations of DNS and Registry Services. I think I know what
> recursion means.
> 
> Now can we go back to actually discussion technical arguments again?

than stop repsond with "That's wrong" if i tell someone forwarding != recursion
because you should know it better and use correct terms



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: default local DNS caching name server

[Reindl Harald]

Am 12.04.2014 17:11, schrieb Paul Wouters:
> On Sat, 12 Apr 2014, Reindl Harald wrote:
> 
>> "we" should not do anything - because "we" don't have a clue about the
>> network of the enduser
> 
> We know and handle a lot more than you think already using unbound with
> dnssec-trigger and VPNs. Why don't you give it a shot and give us some
> feedback on how it works for you on your laptop?

because i stopped to use laptops years ago?
because i have way too complex dns setups for such magic?
because i don't touch NM in that life?

i speak in that thread as one who understands the pain of playing with
DNS and what happens if assumtions are made wrong

>> if the roadrunner has the VPN client directly on his machine, well
>> then he needs to make a decision:
> 
> They needs to make no decision, it has been automated already:
> 
> https://github.com/libreswan/libreswan/blob/master/programs/_updown.netkey/_updown.netkey.in
> 
> if [ -n "$(pidof unbound)" ]; then
> echo "updating local nameserver for ${PLUTO_PEER_DOMAIN_INFO} with 
> ${PLUTO_PEER_DNS_INFO}"
> /usr/sbin/unbound-control forward_add ${PLUTO_PEER_DOMAIN_INFO} 
> ${PLUTO_PEER_DNS_INFO}
> /usr/sbin/unbound-control flush_zone ${PLUTO_PEER_DOMAIN_INFO}
> /usr/sbin/unbound-control flush_requestlist
> return 0
> fi

and if you cross my street with a users machine give me a single button to 
disable
that because you break my setups with that - no i can't explain internal 
infrastructure
in the public but there has to be no local cache in my way

if a co-worker asks for a dns-record, tried to call the site already you have no
business to have a negative cache on the client while all 4 internal nameservers
where two are already caching-servers for external responses and used as 
forwarder
for non-auth zones have already the answer

DNS1: cache
DNS2: cache
DNS3: auth for 600 zones
DNS4: auth for 600 zones

users asking DNS1 and DNS2
they are doing recursion

DNS3 and DNS4 are for public access from the internet to resolve customer 
domains



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: default local DNS caching name server

[Reindl Harald]

Am 12.04.2014 17:05, schrieb Paul Wouters:
> On Sat, 12 Apr 2014, Reindl Harald wrote:
> 
>> nonsense - there are so much ISP nameservers broken out there
>> responding with wildcards and so on that you can not trust them
>> and you will realize that if not before after you started to run
>> a production mailserver which relies on NXDOMAIN responses for
>> proper operations
> 
> That's not what the http://atlas.ripe.net/ data set indicates. Your
> story seems anecdotal and incidental.

if you call the year 2012 anecdotal then yes

> Yes, there are a few bad players out there (like Rogers in Canada) but
> those are in a minority

it is not a matter of bad players, it is a matter of stupid admins
on ISP sides - the case of our server was the largest ISP here and
they simply had bugs in der load-balcing resulting in random results
(current and outdated) from the same nameserver IP

another one was also a large ISP which started 2013 to give that
wrong answers for our ipv4 address in 2013 because they fucked up
their DNS due try to implement ipv6

in both cases i know for sure what happened at the ISP
note that the change was done in 2011 and we are even the GLUE record

another big player at that time was OpenDNS

sicne there are not too much DNS servers of ISP answering to non customer
ip addresses i found around 50 public nameservers all over the world and
15 of them where wrong after more than 7 months - yes it is a minority
because it's below 50% but *way too much* for such a critical service
like DNS

and here i did not talk a single time about overloaded and not responding
IPS DNS again and again - we had many years massive troubles to access
websites and it was always "could not be found" in Firefox which means
no DNS answer - guess what - after no longer using forwarders nobody
has seen that message again



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: default local DNS caching name server

[Reindl Harald]

Am 12.04.2014 16:55, schrieb Paul Wouters:
> On Sat, 12 Apr 2014, Reindl Harald wrote:
> 
>> a DNS server doing recursion don't ask any forwarder
> 
> That's wrong. a DNS server can use a forwareder for some or all of its
> recursive queries. unbound+dnssec-triggerd mostly cause unbound to do
> full recursion but using the ISP nameserver as forward for all queries.

oh no - please try to understand what recursion means in case of DNS

may i suggest to read some docs because if i talk about DNS as one
who maintains 600 domains as DNS provider as well as Registry for
the .at domain and implemented DNS admin-backends years ago i know
what i am talking about

recursion is by definition

* ask the root server for example.com
* answer of the root is "dunno, but you can ask xxx for .com"
* your DNS asks xxx for example.com
* answer of xxx is "dunno, but you can ask ns1.whoever.tld for example.com"

forwarding bypasses that and asks your ISP's or whatever configured
nameserver and never the root, so no, you don't do recursion in that
case, your forwarder may do or at least the last forwarder if the
DNS you asking itself does forwarding too - but that's not your
business then and you don't to recursion



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: default local DNS caching name server

[Reindl Harald]

Am 12.04.2014 16:16, schrieb Chuck Anderson:
> On Sat, Apr 12, 2014 at 04:03:14PM +0200, Reindl Harald wrote:
>> Am 12.04.2014 15:31, schrieb Chuck Anderson:
>>> I disagree.  You can still do DNSSEC validation with a local caching
>>> resolver and configure that local resolver to forward all queries to
>>> the ISP.  That should be tried first, and only bypassed and become a
>>> full interative recursive querier bypassing the ISP resolvers if that
>>> fails.  We need to respect the DNS caching infrastructure by default.
>>
>> nonsense - there are so much ISP nameservers broken out there
>> responding with wildcards and so on that you can not trust them
>> and you will realize that if not before after you started to run
>> a production mailserver which relies on NXDOMAIN responses for
>> proper operations
> 
> I don't disagree that there is lots of broken DNS out there.  But
> realistically, we still need to default to using the DHCP-provided DNS
> servers as forwarders because there are unfortunately lots of
> circumstances where this is required to resolve corporate DNS names or
> to allow captive portals to work.

if you rely on that and are a road-wwarrior don't setup a local dns

> If the local caching resolver is
> intelligent enough, it can handle the common use cases (corporate DNS
> resolution, VPN into corporate, captive portals) and work around the
> common failure modes (automatic cache flushing, switching to iterative
> mode to bypass upstream nameservers when necessary, using both the
> upstream nameservers AND iterative queries and combining the results)
> for us.

oh no - go away with such ideas

there is nothing like "intelligent" in case of a DNS resolver
the only thing you achieve trying that is unpredictable behavior

> What we cannot do is have the default be to bypass the upstream DNS
> resolvers without some way to handle the above cases.  If mainstream
> operating systems started doing that by default, then corporate
> networks, ISPs, captive portals etc. will probably start blocking DNS
> to outside servers or redirecting port 53 to their own servers.  In
> fact some already do this.  We don't want to escalate the arms race by
> encouraging this behavior

"we" should not do anything - because "we" don't have a clue about the
network of the enduser - if he is a road-warrior then he needs to use
DHCP provided nameservers, if he is a roadrunner and has at home VPN
access to his company network he has to enter the DNS servers behind
the VPN into his router / dhcp and after coming home all works as
expected

if the roadrunner has the VPN client directly on his machine, well
then he needs to make a decision:

* enter the company nameservers in /etc/resolv.conf and always use VPN
* enter the company LAN hostnames in /etc/hosts to not rely on DNS at all
* manually change /etc/resolv.conf whenever needed

there is nothing to gain with trying auto-magic for sensible things like DNS



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: default local DNS caching name server

[Reindl Harald]

Am 12.04.2014 15:31, schrieb Chuck Anderson:
> On Sat, Apr 12, 2014 at 02:09:19PM +0800, P J P wrote:
>>> On Saturday, 12 April 2014 11:11 AM, William Brown wrote:
>>> Say I have freshly installed my fedora system at home. I then boot it up
>>> and start to use it. My laptop is caching DNS results all the while from
>>> the "unreliable" ISP.
>>>
>>> I then go to work and suddenly things don't work.
>>>
>>> Having a DNS cache doesn't fix your unreliable ISP: You need to lodge a
>>> complaint with your ISP.
>>
>>   What, no! that was the case for having local cache and not forwarding 
>> queries to the ISP's name servers at all. Because those are not reliable.
> 
> I disagree.  You can still do DNSSEC validation with a local caching
> resolver and configure that local resolver to forward all queries to
> the ISP.  That should be tried first, and only bypassed and become a
> full interative recursive querier bypassing the ISP resolvers if that
> fails.  We need to respect the DNS caching infrastructure by default.

nonsense - there are so much ISP nameservers broken out there
responding with wildcards and so on that you can not trust them
and you will realize that if not before after you started to run
a production mailserver which relies on NXDOMAIN responses for
proper operations

there are also a lot of broken DNS servers in general not respecting
the TTL - not so long ago we moved one of our servers into our
datacenter, changed the TTL to 5 minutes two days before and
*7 months* later the DNS of my private ISP answered randomly with
the old and the new address

other DNS servers out there answered after 7 months still with the old
the most broken one just answered with *both* suggesting round robin to
the client - problem: the old IP did no longer exist at all

how i tested that?
by google for public answering nameservers, ask all which i found
with a script and finally asked the tech contact of the broken ones
why they not start to hire someone with the skills for DNS



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: default local DNS caching name server

[Reindl Harald]

Am 12.04.2014 13:25, schrieb William Brown:
>>> Consider, I get home, and open my laptop. Cache is cleared,
>>> and I'm now populating that cache with the contents from the ISP.
>>
>>   No, why contents from ISP? Local resolver will populate cache from root 
>> servers, no?
> 
> This isn't how DNS works . You populate your cache from the ISP, who
> queries above them and so on up to the root server.

no - only if you enter your ISP's servers as forwarder which
makes only partial sense because it lowers the effective TTL
and you have more and more cahcings between the origin and
your machine while some of them may ignore TTL at all

a DNS server doing recursion don't ask any forwarder

> http://technet.microsoft.com/en-us/library/cc961401.aspx

nice, but you need to understand the contents especially
point 3 and because point 1-8 it is called "recursion"
because you sart to ask the root-servers which tell you
"hey i don't konw the address, but i know who knows .com"
followed by the server for .com answers "well, i don't
know the answer but i can tell you who knows"




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

Re: F21 System Wide Change: The securetty file is empty by default

[Reindl Harald]

Am 11.04.2014 16:30, schrieb Jaroslav Reznik:
> === Description ===
> An empty /etc/securetty file prevents root login on any devices attached to 
> the computer.
> 
> === Effects ===
> Prevents access to the root account via the console or the network. The 
> following programs are '''prevented''' from accessing the root account: login

interesting how someone manages a stripped down machine only having
a root account and nothing else or how do you imagine that on machines
with all users except the local root are on network services in case
of troubleshooting the network setup

i also can't remember that the RHEL7-Beta1 i installed in 2013/12
had any other account than root for the final setup

especially in case your network card is not supported until a kernel update
you are unable to setup the OS at all because you need to download the new
kernel somewhere else, put it on a USB media, login as local root and update
the machine - happened 2011 with Fedora 14 on real hardware for me

on servers running virtual machines that is also the last ressort if
ssh breaks which happens easily in case only key-auth is allowed and
you are at switching all ssh-keys on a infrastructure

changes in ~/.ssh/authorized_keys get active instantaneously

frankly it happened twice to me last december due changing all ssh-host-kyes
and private keys to 3072 bit keylength that i needed a local root login
for allow temporary password-login over SSH and get the new public key
on the machine - without the local root account and in case of encrypted
disks you are mostly done with that machine with the new defaults

hence is why you should re-consider lock out the local root in a default
setup which needs physical access while the door for SSH login with the
password over the network is opened - the other way around would make sense



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: trimming down Fedora installed size

[Reindl Harald]

Am 10.04.2014 00:00, schrieb Jóhann B. Guðmundsson:
> 
> On 04/09/2014 09:12 PM, Ralf Corsepius wrote:
>> On 04/09/2014 10:05 PM, Billy Crook wrote:
>>> I would like to see logic like this:
>>> manpage files don't get installed unless/until:
>>> 1) packagename-manpages is requested to be installed by the user.  that
>>> package would require the 'man' package.
>>> OR
>>> 2) package is installed AND man is installed.
>>
>> In other words, you want to crippled end-user usability to NULL.
> 
> I would not be dwelling to much on the usability topic since we have bigger 
> issues to fry then end-user usability
> with minimal installation footprint for cloud/containers/servers which can be 
> easily solve with same concept as is
> behind "command-not-found" for man-pages as in "man-page-not-found" and move 
> cloud/container/server administration
> into the realm of "install on demand" ( which arguably we should be moving 
> more towards at on the 21 century rather
> then rely on plethora of installation commands and package names ) and 
> ofcourse we would remove the silliness of
> having to confirm the installation since I as an administrators have already 
> made the gesture that I need the
> command or the man page when I write foo or man foo so I should not have to 
> confirm it to

no - if i type "man whatever" and that starts to pull 10 MB packages i stop
and think 5 seconds if there is one of my ,ore than 30 machines which have
it already



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: trimming down Fedora installed size

[Reindl Harald]

Am 09.04.2014 23:01, schrieb Billy Crook:
> On Wed, Apr 9, 2014 at 3:41 PM, Reindl Harald  <mailto:h.rei...@thelounge.net>> wrote:
> 
> 
> Am 09.04.2014 22:05, schrieb Billy Crook:
> > I would like to see logic like this:
> > manpage files don't get installed unless/until:
> > 1) packagename-manpages is requested to be installed by the user.  that 
> package would require the 'man' package.
> > OR
> > 2) package is installed AND man is installed.
> >
> > Don't wan't the manpages taking up disk space?  remove the 'man' 
> package and all manpages disappear.
> > Don't use en_US and don't want to waste space on that either, remove 
> the 'localization-en_US' package and its
> > corresponding localizations of all installed packages will dispapear too
> 
> packages i build at my own have "package-manpages" for any man/doc parts
> on all the servers i maintain they are not installed
> it's enough to have them on *one* central admin server
> 
> 
> heck, on my desktop I might end up just yum installing *-manpages to save 
> time later

really?

compared how often i reinstall a workstation (never) and how often
i need a manpage because "command --help" don't answer the question
that is unlikely

how many manpages do you have installed and how many of them
you ever viewed in the past let say 5 years?

escpecially because the goal is to seperate things which does *not*
mean they are not installed in most setups - a meta-package "postfix"
can pull "postfix-server" and "postfix-manuals" while you can remove
the metapackage and "postfix-manuals"



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: trimming down Fedora installed size

[Reindl Harald]

Am 09.04.2014 22:05, schrieb Billy Crook:
> I would like to see logic like this:
> manpage files don't get installed unless/until:
> 1) packagename-manpages is requested to be installed by the user.  that 
> package would require the 'man' package.
> OR
> 2) package is installed AND man is installed.
> 
> Don't wan't the manpages taking up disk space?  remove the 'man' package and 
> all manpages disappear.
> Don't use en_US and don't want to waste space on that either, remove the 
> 'localization-en_US' package and its
> corresponding localizations of all installed packages will dispapear too

packages i build at my own have "package-manpages" for any man/doc parts
on all the servers i maintain they are not installed
it's enough to have them on *one* central admin server



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: Reinstalling the bootloader

[Reindl Harald]

Am 04.04.2014 04:44, schrieb Andrew Lutomirski:
> On Apr 3, 2014 7:18 PM, "Reindl Harald"  wrote:
>> besides that it is the wrong list:
> 
> What's the right list?

the users list, not the developers list

>> grub2-install
> 
> $ grub2-install
> /usr/sbin/grub2-probe: error: cannot find a GRUB drive for /dev/sda1.
> Check your device.map.

/dev/sda1

grub2-install /dev/sda
don't install GRUB2 these days into a partition

grub2 was a challenge on installations running for many years
because in that case you need to shrink the frist partition
and move it so that there is enough space before



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: Reinstalling the bootloader

[Reindl Harald]

Am 04.04.2014 03:08, schrieb Andrew Lutomirski:
> Once upon a time (Fedora 15? -- I've lost track), it was possible to 
> reinstall the bootloader using grub-install.

besides that it is the wrong list: grub2-install

> Nowadays it's a clusterfsck.  I've managed to screw up my bootloader.  Is 
> there a way to reinstall it without
> reinstalling the world?  Would it make sense to split the whole bootloader 
> thing out of Anaconda such that it would
> be possible to re-run it?  I can access my install just fine using chroot.
> 
> FWIW, the same question applies to upgrading the bootloader.  Somehow I'm on 
> Fedora 20 using grub 0.97

how comes? grub2 took over with F16 or F17



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: systemd bugs in F20/F21 -> bug against the distribution?

[Reindl Harald]

Am 03.04.2014 22:46, schrieb Martin Langhoff:
> On Thu, Apr 3, 2014 at 4:41 PM, Reindl Harald  wrote:
>> Am 03.04.2014 22:32, schrieb Adam Williamson:
>>> On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
>>>> will that below ever get fixed in F20?
>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1072368
>>>
>>> The developer does not consider it to be a bug. You may disagree, but so
>>> far, you don't seem to have convinced him or any other systemd
>>> developers or, well, anyone else.
>>
>> than the developer should explain his point of view and
>> ask for further input instead react with WONT FIX
> 
> Reindl. You are reading to retort, not to understand

i understand more than you imagine

but you need also to understand that a "WON'T FIX" for the reporter
of a bug is the same as spit into his face and so the only correct
reaction of a developer is:

* explain his point of view
* wait for a addtional response
* hestitate to press "NO BUG" or "WON'T FIX" aka "leave me in peace"

if developers are not greatful for users input users are not greatful
for breaking and changing things right and left of them which worked
as expected before



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: systemd bugs in F20/F21 -> bug against the distribution?

[Reindl Harald]

Am 03.04.2014 22:37, schrieb Richard Hughes:
> On 3 April 2014 20:00, Adam Jackson  wrote:
>> We didn't, and no justification would matter.  It's not acceptable
>> behaviour, and you need to knock it off.
> 
> I'm not the only developer considering unsubscribing from fedora-devel
> because of emails like the original email. 

what exactly is your personal problem with that original mail?
exceot taht you don't like me?

> Either the moderators start enforcing stricter rules, warning and then 
> banning certain users, on the number of developers on this "-devel" 
> mailing list is going to start going down really fast. Without developers 
> this mailing list is pointless.

speak for yourself and not for others - opposite to people like
Lennart, Kay and yourself other including me don't need moderation
and killfiles to not face critism




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: systemd bugs in F20/F21 -> bug against the distribution?

[Reindl Harald]

Am 03.04.2014 22:32, schrieb Adam Williamson:
> On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
>> will that below ever get fixed in F20?
> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1072368
> 
> The developer does not consider it to be a bug. You may disagree, but so
> far, you don't seem to have convinced him or any other systemd
> developers or, well, anyone else.

than the developer should explain his point of view and
ask for further input instead react with WONT FIX

>> https://bugzilla.redhat.com/show_bug.cgi?id=1010572
> 
> This is an entirely trivial issue: a failed attempt to access something
> with no apparent negative consequences. Doesn't seem like it'd be a high
> priority. It also doesn't seem like it would be too difficult to track
> down and propose a fix, if it's bugging you so much.

i expect from a serious developer to face that message because i
expect that he reads his syslogs, if it is meaningless than the
code around of that is also meaningless and has to be removed
for the sake of clean software

>> https://bugzilla.redhat.com/show_bug.cgi?id=626477
> 
> You yourself have reported in
> https://bugzilla.redhat.com/show_bug.cgi?id=626477#c44 that this is
> fixed on the systemd 208 branch, which F20 is tracking. Then you went
> nuts and started yelling at people, which as you've been told fifty six
> thousand goddamn times by now, never ever helps. From the latest
> comments it sounds like whenever f20 is updated to the latest
> systemd-208 code, this fix will come in. It's up to the package
> maintainer when they want to do that.

well, if someone reports problems and even has testing environments
as well is willing to verify and test he can expect respect in form
of a scratch build

>> https://bugzilla.redhat.com/show_bug.cgi?id=1047148
> 
> Apparently fixed in 20 and Rawhide, you just want a backport to 19?

since the "no distributeable systemctl reboot" and much more the scary
fact that a workaround is based ona typo prevents from update any
production server to F20 i will face that until F20 is useable in
production which is not the case caused by systemd - chicken/egg problem

>> https://bugzilla.redhat.com/show_bug.cgi?id=1024379
> 
> Is another extremely trivial one: you're throwing your toys out of the
> pram over slightly sub-optimal autocomplete? Really?

it's anotehr drop into a full sea and affects my workload all the time
because i distribute commands from one machine having all packages
installed

systemctl stop whatever.service; do something; do something; systemctl start 
whatever.service





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: systemd bugs in F20/F21 -> bug against the distribution?

[Reindl Harald]

Am 03.04.2014 22:04, schrieb Kevin Fenzi:
> Bad behavior in response to bad behavior just feeds a positive feedback
> cycle ( http://en.wikipedia.org/wiki/Positive_feedback ). 
> 
> The way to break out of it is for the person you control (namely YOU)
> to behave well. If others don't do so, things can calmly escalate and
> proper measures taken.
> 
> So, be reasonable. Use logical arguments to convince maintainers that
> your bug is reasonable and your proposed solutions or patches are also
> reasonable. If you cannot do this, step back and let others do so. 

what logical arguments do you have if the developer is living in his
own world where he is happy about every log message "his baby" writes
while at the same time that burries critical and relevant messages for
anybody else who cares?

you can come up with logical arguments in case of interested
developers but not in case of "we do what we want, break what
we want when we want to break it and everything falling left
and right is buggy and wrong" developers

> If the problems are persistent or highly impact-full, it's likely that
> higher levels of project management may get involved, but only in good
> time and after looking at the behavior of all the parties involved.

writing thousands of log-lines on a completly stripped down Rawhide
VM with only the default cronjobs *is highly impact-full* because
on production workloads and a central machine receiving all that
messages and store them in a database that is a DOS attack

if there would be a prefix or a specific binary thrwoing all that
messages you could filter them out in rsyslog.conf (by keep useless
overhead burried) but not the way it is implemented

"use journalctl and filter out" is pure ignorance



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: systemd bugs in F20/F21 -> bug against the distribution?

[Reindl Harald]

Am 03.04.2014 21:44, schrieb Martin Langhoff:
> On Thu, Apr 3, 2014 at 3:08 PM, Reindl Harald  wrote:
>> Am 03.04.2014 20:00, schrieb Adam Jackson:
>>> On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
>>>
>>>> and if someone asks why i called Lennart in #1072368
>>>> names
>>>
>>> We didn't, and no justification would matter.  It's not acceptable
>>> behaviour, and you need to knock it off.
>>
>> i know that -
> 
> Then do. Your behavior is toxic, don't excuse it with others' behavior

as explained most of that behavior started with F15 and destroy years
of optimization on perfect running systems which now repeats by put
the head in the sand, ignore problems over months and if a reaction
besides ignore happens it is "close because i don't care"

there is a reason today even Linus choosed words like "and I personally
find it annoying that it's always the same f*cking primadonna involved"
in direction of systemd-upstream



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: systemd bugs in F20/F21 -> bug against the distribution?

[Reindl Harald]

Am 03.04.2014 20:00, schrieb Adam Jackson:
> On Thu, 2014-04-03 at 19:31 +0200, Reindl Harald wrote:
> 
>> and if someone asks why i called Lennart in #1072368
>> names
> 
> We didn't, and no justification would matter.  It's not acceptable
> behaviour, and you need to knock it off.

i know that - on the other hand developers need to knock
out the reflex "your bugreport annoys me" and close it
within minutes because they don't care about users

and only if *both sides* starts to play nicely it can work
and one part of that is to *respect* reporters and realize
taht report bugs and describe problems in daily use is
a important sort of contribution - i am developer too and
i am well aware without the users point of view i would
develop blindly - anybody not awawre of this should stop
calling himslef a serious developer

developers need to knock of that attitude:
https://bugs.freedesktop.org/show_bug.cgi?id=76935#c10

without users the developers would be meaningless



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: systemd bugs in F20/F21 -> bug against the distribution?

[Reindl Harald]

Am 03.04.2014 19:54, schrieb drago01:
> On Thu, Apr 3, 2014 at 7:52 PM, Reindl Harald  wrote:
>>
>>
>> Am 03.04.2014 19:47, schrieb drago01:
>>> Note: I didn't look at the bugs
>>
>> then please don't answer at all
> 
> What I wrote does not depend on what the bugs actually are

it does and honestly bugs which are reported before release
and open 7 months later in a core-component ar enot doing
the distribution a favour as well as upstream developers
of such a component even discuss against kernel upstream
that they are doing the right thing until Linus has that
muche enough to impend prohibit one of the core developers
to commit code in the future

this ignorance against downstream and users and break things
careless which where not broken, make maintaining machines
more and more complicated by spew nonsense in the logs and
demand users to change their way of work to make upstream
happy is a real bad attitude and in case of "but reportes
are not friendly enough" - well, cause and effect

>> It does become a problem when you have a system service
>> developer who thinks the universe revolves around him,
>> and nobody else matters, and people sending him bug-reports
>> are annoyances that should be ignored rather than acknowledged
>> and fixed. At that point, it's a problem.



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: systemd bugs in F20/F21 -> bug against the distribution?

[Reindl Harald]

Am 03.04.2014 19:47, schrieb drago01:
> Note: I didn't look at the bugs

then please don't answer at all



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

systemd bugs in F20/F21 -> bug against the distribution?

[Reindl Harald]

will that below ever get fixed in F20?
should i file a bug against the distribution?
should i file a bug against Red Hat as upstream employer?

and if someone asks why i called Lennart in #1072368
names - because over weeks nobody cared and after i
asked again on this list within 5 minutes Lennarts first
reaction within 5 minutes was close the bugreport because
he decides what is OK for users and don't care that about
different worksloads

in that context 2 links with a quote of Linus 100% matching:
>> It does become a problem when you have a system service
>> developer who thinks the universe revolves around him,
>> and nobody else matters, and people sending him bug-reports
>> are annoyances that should be ignored rather than acknowledged
>> and fixed. At that point, it's a problem.

https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF
http://www.spinics.net/lists/kernel/msg1716484.html


https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1010572
https://bugzilla.redhat.com/show_bug.cgi?id=626477
https://bugzilla.redhat.com/show_bug.cgi?id=1047148
https://bugzilla.redhat.com/show_bug.cgi?id=1024379



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: [CHANGE PROPOSAL] The securetty file is empty by default

[Reindl Harald]

Am 03.04.2014 16:32, schrieb quickbooks office:
> This change will not affect logging into the console using the local
> account and then doing su to get root privileges.
> 
> Is there a problem with logging into the local user account and then
> typing su and the root password?

i do *not* need a local user account on machines typically running
without any local user and *if i need to login there* i do that
*because* i need to maintain that machine as root

and that is why i *do not* have a user besides root because all
other users for cronjobs and services have no shell at all

so no, don't break useful setups with defaults



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

Re: F21 System Wide Change: lbzip2 as default bzip2 implementation

[Reindl Harald]

Am 02.04.2014 20:18, schrieb Mikolaj Izdebski:
>>> lbzip2 is a mature project and it has been used in production for years. It 
>>> is 
>>> already packaged for Fedora and it is also available in EPEL.
>>
>> A quick check shows lbzip2 doesn't provide a library interface, much less
>> one compatible with libbz2. Is that ever intended?
> 
> That was once intended (in 2007-2010), but for now I decided to provide
> bzip2-compatible commands only.  If there is demand I will reconsider
> providing a library with bzip2-compatible API/ABI.
> 
>> If it's not, saying lbzip2 is the default bzip2 *implementation* may be a
>> bit of a stretch. Perhaps s/implementation/command/.
> 
> You're right, the title and description may be ambiguous.  In this
> sentence "bzip2" means bzip2 command

packages using the library (output of yum remove bzip2-libs-1.0.6-9.fc20.x86_64)

--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket gnupg-1.4.16-2.fc20.x86_64 
verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
perl-Compress-Raw-Bzip2-2.062-2.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
libsemanage-2.1.10-14.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
ImageMagick-c++-6.8.6.3-3.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
6:kdelibs-4.12.3-1.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
ffmpeg-libs-2.1.4-4.fc20.20140324.rh.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket bzip2-1.0.6-9.fc20.x86_64 
verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
ffmpeg-compat-0.6.7-4.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
python-deltarpm-3.6-3.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
libarchive-3.1.2-7.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
gnome-vfs2-2.24.4-14.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
elfutils-libs-0.158-1.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
elinks-0.12-0.36.pre6.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket deltarpm-3.6-3.fc20.x86_64 
verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
rpm-build-libs-4.11.2-2.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket rpm-4.11.2-2.fc20.x86_64 
verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
gstreamer-plugins-bad-free-0.10.23-20.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket unzip-6.0-12.fc20.x86_64 
verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
php-5.5.10-2.fc20.20140306.rh.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
ImageMagick-libs-6.8.6.3-3.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
GraphicsMagick-1.3.18-4.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket zip-3.0-9.fc20.x86_64 
verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
php-cli-5.5.10-2.fc20.20140306.rh.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
ImageMagick-6.8.6.3-3.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
gstreamer1-plugins-bad-free-1.2.3-1.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
gstreamer-ffmpeg-0.10.13-11.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
strigi-libs-0.7.8-2.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
python3-libs-3.3.2-11.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
clamav-lib-0.98.1-1.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
genisoimage-1.1.11-22.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
gnupg2-2.0.22-1.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
rpm-libs-4.11.2-2.fc20.x86_64 verarbeitet
--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
2:gimp-2.8.10-4.fc20.x86_64 verarbeitet

--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
python-libs-2.7.5-11.fc20.x86_64 verarbeitet

--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
ffmpeg-latest-2.2-2.fc20.20140324.rh.x86_64 verarbeitet

--> Abhängigkeit libbz2.so.1()(64bit) wird für Paket 
tokyocabinet-1.4.48-2.fc20.x86_64 verarbeitet



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: [CHANGE PROPOSAL] The securetty file is empty by default

[Reindl Harald]

Am 02.04.2014 19:29, schrieb Chris Adams:
> Once upon a time, Jaroslav Reznik  said:
>> - Original Message -
>>> [CHANGE PROPOSAL] The securetty file is empty by default
>>>
>>> All the info has been sitting here @
>>> https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default
>>> since March 20th.
>>>
>>> Did I mess something up? Or is there just a backlog?
>>
>> Backlog. But for this one, I'd really like to see some discussion
>> in advance of the real announcement. So thank you for this email.
> 
> I'd be opposed to locking root out of the console login (having spent
> today at work tracking down miscellaneous VMs with only a root user
> created)

+1

a golden-master for a virtual infrastructure usually do not
have any other login user because which one is decided after
clone and intention of the final machine instead some generic
user

> Fedora still allows root SSH logins by default; how is that more secure
> than the console?

it is not but disable that in a default install makes nothing more secure
the only secure SSH setup is that one where no password login is allowed
and that is a chicken/egg problem not solveable at setup



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 29.03.2014 15:54, schrieb Orion Poplawski:
> What gives you the impression that fail2ban is "crusty"?  It's being
> actively developed upstream and integrates with firewalld now.  Are
> those particularly onerous dependencies?

and that is the problem / difference to tcpwrapper
it integrates in the firewall / iptables

so you have *not* additional security layer, you have
a single layer with a single point of failure and if
iptables for hwatever reason does not work as it should
you are lost

* bug in the rules failing iptables / forewalld to start
* SELinux failing iptables / forewalld to start
* bug in the iptables-rules render it useless (ACCEPT before REJECT/DROP)

if it ever comes to security you must not have a single protection layer
and some others appearing to exist but rely on that single layer makes
things even worser - /etc/hosts.deny works independent of SELinux or iptables



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 28.03.2014 14:48, schrieb Petr Lautrbach:
> On 03/28/2014 02:44 PM, Reindl Harald wrote:
>>> - every change in sshd_config has to be confirmed by sshd restart, while 
>>> changing hosts.deny doesn't need
>>> any other action
>>
>> no - try it out!
>>
>> make a fatal syntax error in "sshd_config" and in case of a
>> remote machine make sure you don't close the last connection
>> because you will not reach the machine again otherwise
> 
> [14:46:53 root@malas ~ ]# /usr/sbin/sshd -T
> /etc/ssh/sshd_config: line 157: Bad configuration option: blbla
> /etc/ssh/sshd_config line 157: Directive 'blbla' is not allowed within a 
> Match block
> [14:46:55 root@malas ~ ]# ssh localhost
> Fedora release 21 (Rawhide)
> root@localhost's password:

not sure which options are connection specific but there
are for sure ones which do not need a restart and get
effective for every new connection, i have not the time
to seek and reproduce that but it's a fact from real
work expierience



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 28.03.2014 14:39, schrieb Petr Lautrbach:
> On 03/20/2014 08:05 PM, Lennart Poettering wrote:
>> On Thu, 20.03.14 12:20, Stephen John Smoogen (smo...@gmail.com) wrote:
>>
 I doubt there are many people even using them anymore, firewalls are
 more comprehensive and a lot more powerful, and while every admin knows
 firewalls, I figure only very few know tcpd/tcpwrap, and even fewer ever
 actively make use of them...


>>> Actually they are used quite a bit in various service worlds. Mainly for
>>> ssh and email for dealing with scanners. [DenyHosts is a boon in this
>>> area.] The reason for using a secondary tool is that depth of
>>> security.
>>
>> Well, all mails servers as well as sshd have much better ways to do
>> such filtering. sshd has "Match",  Postfix for example has
>> "smtpd_client_restrictions=", and so on.
> 
> I'd like to note that you can't just replace deny.hosts using Match block in 
> sshd_config.
> 
> - using libwrap, a connection is dropped before the protocol version exchange 
> so a client can't even check the server's
> identification string. While using Match block, a client and a server 
> exchange id strings, negotiate the transport layer
> parameters, exchange keys and establish encrypted connection.

which is *layered* security

that is the same reason why "put the rules in iptables" is only
a uneducated phrase and anybody who will put all his security
in a single layer sooner or later regret that mistake

> - every change in sshd_config has to be confirmed by sshd restart, while 
> changing hosts.deny doesn't need
> any other action

no - try it out!

make a fatal syntax error in "sshd_config" and in case of a
remote machine make sure you don't close the last connection
because you will not reach the machine again otherwise



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: NetworkManager "forget" user network configurations: bug or feature?

[Reindl Harald]

Am 26.03.2014 22:47, schrieb Kevin Kofler:
> Sergio Belkin wrote:
>> Hmmm... but NetworkManager should think in desktop users (ok, somewhat
>> power desktop users) that install a new release/distro and a user
>> configuration should be completely independent. Or at least give the
>> chance to save either systemwide or "userwide". Anyway thanks for your
>> answers and ideas, I understand that all of this is somewhat Off-Topic :)
> 
> Desktop users are supposed to upgrade, not reinstall. :-)

server users even more
that below was Fedora 9 at install 2008 like 20 other machines

[root@buildserver:~]$ cat /etc/redhat-release
Fedora release 19 (Schrödinger’s Cat)

[root@buildserver:~]$ tune2fs -l /dev/sdb1
tune2fs 1.42.7 (21-Jan-2013)
Filesystem volume name:   system
Last mounted on:  /
Filesystem UUID:  918f24a7-bc8e-4da5-8a23-8800d5104421
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  has_journal ext_attr resize_inode dir_index filetype 
needs_recovery extent flex_bg
sparse_super large_file uninit_bg dir_nlink
Filesystem flags: signed_directory_hash
Default mount options:journal_data_writeback user_xattr acl nobarrier
Filesystem state: clean
Errors behavior:  Continue
Filesystem OS type:   Linux
Inode count:  524288
Block count:  2097144
Reserved block count: 2
Free blocks:  1290263
Free inodes:  414241
First block:  0
Block size:   4096
Fragment size:4096
Reserved GDT blocks:  383
Blocks per group: 32768
Fragments per group:  32768
Inodes per group: 8192
Inode blocks per group:   512
Filesystem created:   Mon Aug 18 06:48:05 2008
Last mount time:  Wed Mar 26 12:09:13 2014
Last write time:  Wed Mar 26 12:09:13 2014
Mount count:  9
Maximum mount count:  -1
Last checked: Wed Jan  8 16:28:17 2014
Check interval:   31104000 (12 months)
Next check after: Sat Jan  3 16:28:17 2015
Lifetime writes:  965 GB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   256
Journal inode:8
Default directory hash:   half_md4
Directory Hash Seed:  1e9d689f-15fe-4c0d-aaba-9d323049c7f4
Journal backup:   inode blocks
[root@buildserver:~]$



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

Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services

[Reindl Harald]

Am 26.03.2014 18:52, schrieb Stephen Gallagher:
> On 03/26/2014 11:30 AM, Reindl Harald wrote:
>> i just tried on F20 and "PrivateDevices" is not known sadly because
>> i have some services in mind where i would like that
> 
>> Mär 26 15:51:55 testserver.rhsoft.net systemd[1]:
>> [/usr/lib/systemd/system/httpd.service:15] Unknown lvalue 
>> 'PrivateDevices' in section 'Service'
> 
> PrivateNetwork seems to have been around since at least 2012. The
> commit providing PrivateDevices[1] went upstream on January 20th.

correct and in use here for longer time

> According to
> git describe 7f112f50fea585411ea2d493b3582bea77eb4d6e
> 
> we get v208-1612-g7f112f5 which means it went in 1,612 patches after
> v208 was released, so it's definitely not in F20 or RHEL 7 beta

which is just bad, after the announcement i planned to configure
postfix, dbmail, dovecot, httpd... on my local testmachine using
PrivateDevices=yes since /dev/urnadom and friends are statet as
available and test out if it is do-able in production

that said the announcement with words like "recent systemd" as
well as the documentation is just poor because it does nowhere
state the required systemd version which reflects the not care
about downstream or users attitude

maybe some people should look at postfix and it's documentation
as reference how sane docs are looking like and improvements
over years are done without breaking backwards compatibility


http://www.freedesktop.org/software/systemd/man/systemd.exec.html

PrivateDevices=
Takes a boolean argument. If true, sets up a new /dev namespace for the 
executed processes and only adds API
pseudo devices such as /dev/null, /dev/zero or /dev/random (as well as the 
pseudo TTY subsystem) to it, but no
physical devices such as /dev/sda. This is useful to securely turn off physical 
device access by the executed
process. Defaults to false. Enabling this option will also remove CAP_MKNOD 
from the capability bounding set for
the unit (see above), and set DevicePolicy=closed (see 
systemd.resource-control(5) for details). Note that using
this setting will disconnect propagation of mounts from the service to the host 
(propagation in the opposite
direction continues to work). This means that this setting may not be used for 
services which shall be able to
install mount points in the main mount namespace.



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

Re: F21 System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For Long-Running Services

[Reindl Harald]

Am 26.03.2014 16:28, schrieb Bill Nottingham:
> Jaroslav Reznik (jrez...@redhat.com) said: 
>> = Proposed System Wide Change: PrivateDevices=yes and PrivateNetwork=yes For 
>> Long-Running Services =
>> https://fedoraproject.org/wiki/Changes/PrivateDevicesAndPrivateNetwork
>>
>> Change owner(s): Lennart Poettering , Dan 
>> Walsh, Kay Sievers
>>
>> Let's make Fedora more secure by default! Recent systemd versions provide 
>> two 
>> per-service switches PrivateDevices=yes/no and PrivateNetwork=yes/no which 
>> enable services to run without access to any physical devices in /dev, or 
>> without access to kind of network sockets. So far this has seen little use 
>> in 
>> Fedora, and with this Fedora Change we'd like to change this, and enable 
>> these 
>> for all long-running services that do not require device/network access. 
> 
> Can you define 'recent' here? While we wouldn't want to change the behavior
> of existing F20 or earlier services, it would be worthwhile to know if
> packages built for EPEL 7 could/should use this feature as well

i just tried on F20 and "PrivateDevices" is not known
sadly because i have some services in mind where i would like that

Mär 26 15:51:55 testserver.rhsoft.net systemd[1]: 
[/usr/lib/systemd/system/httpd.service:15] Unknown lvalue
'PrivateDevices' in section 'Service'



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: leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]

[Reindl Harald]

Am 25.03.2014 15:54, schrieb Jóhann B. Guðmundsson:
> On 03/25/2014 02:41 PM, Reindl Harald wrote:
>> stop your destructive FUD, without users developers and contributors are 
>> *meaningless*
>> and with throwing alpha-state software to the users and make them bleed all 
>> the
>> time you will end in no users at all
>>
>> if you don't understand that, don't care for users and don't like Fedora
>> as you statet often enough because you hate Redhat, well, you know what
>> you have to do
> 
> I think you should keep your mouth shut accusing me of destructive FUD

i can seek in the archives how often you attack Redhat and so on
https://lists.fedoraproject.org/pipermail/devel/2013-February/177915.html

> I'm not the one that is calling developers idiots [1] 

you state [1] two times and list it once with a broken link

here we go: https://bugzilla.redhat.com/show_bug.cgi?id=1072368

nobody right in his mind states *18* loglines for every single
cronjob are fine - multiply that with 85 cronjobs on our main
server, some of them every minute for good reasons

then you have 2 additional lines in /var/log/cron and a
few in /var/log/secure - frankly call that a self-DOS in
case of a central logserver for 30 machines with a database
backend to feed own filter and search applications
___

well deserved in case "flood logs is fine" while that is a naked Rawhide VM
and a production server with cronjobs would produce many ten if not hundret
thousands of log messages leading to no longer face serious ones and without
useful prefixes to filter them outin rsyslog.conf

> then complain about them adding you to their killfile list [2]

the problem with Lennart is that he can't stand *any* critism
and is pissed off or ignoring anything people tell him

bugreports are ignored over months and then after list them
again all commented within minutes - fine

no reply - interesting
http://www.spinics.net/lists/fedora-devel/msg196606.html

> The fact is all the distribution are deprecating tcpwrappers and denyhosts 
> along with it including Debian [1] due to it being maintained and a 
> security risk

don't mix two things
where is the security relevant bug of tcpwrappers?

"it did not get new versions" is not a problem

only people like you don't understand that things which ain't
broken don't need to be fixed and get new bugs due that

> But hey let's keep Fedora out of sync with other distribution and 
> hold progress back to please your usecase

*what progress*
*what are you missing*

> 1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=7327122

is broken and don't exist at debian nor at Redhat

> 2. https://lists.fedoraproject.org/pipermail/devel/2014-March/197093.html
> 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732712



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: leading vs. bleeding [was Re: Maybe it's time to get rid of tcpwrappers/tcpd?]

[Reindl Harald]

Am 25.03.2014 15:22, schrieb Jóhann B. Guðmundsson:
> On 03/25/2014 01:24 PM, Matthew Miller wrote:
>> On Mon, Mar 24, 2014 at 09:17:20PM +0100, Reindl Harald wrote:
>>>> For the record Fedora is not a bleeding edge distro anymore or first in 
>>>> anything
>>> maybe some people should consider the difference between "leading" and 
>>> "bleeding"
>>> smart: leading if things are ready
>>> dumb:  bleeding for any price
>> I agree with Harald here. I think some people have always wanted it to be,
>> but Fedora never really has been chartered to be "bleeding". To quote the
>> "first" foundation more fully:
>>
>>First represents our commitment to innovation. We are not content to let
>>others do all the heavy lifting on our behalf; we provide the latest in
>>stable and robust, useful, and powerful free software in our Fedora
>>distribution.
>>
>> Note "latest in stable and robust", not "latest bleeding edge". There is
>> supposed to be a balance here.
>
> Leading and bleeding go hand in hand being "first"

no, the is a sharp line to draw

> In this particular case we already are years behind Arch and soon to be 
> behind 
> OpenSuse and others aswell

as long as you do not make any points this is FUD

> So if this is the case when people want to modernize and cleanup the 
> distribution then 
> perhaps it's time for the board revisit and redefine the foundation for firs 
> so 
> contributors can avoid Fedora and move to more acceptable distribution of 
> their 
> contributions like Arch if they want to be part of distribution that is 
> leading and is "first"

stop your destructive FUD, without users developers and contributors are 
*meaningless*
and with throwing alpha-state software to the users and make them bleed all the
time you will end in no users at all

if you don't understand that, don't care for users and don't like Fedora
as you statet often enough because you hate Redhat, well, you know what
you have to do



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 24.03.2014 22:53, schrieb Jóhann B. Guðmundsson:
> By the way the kernel does not have a proper deprecation process which is 
> accurately reflected in all the code that
> is bit-rotting there so it's not the holy grail of code maintenance as you 
> let it out to be

the kernel at least has the rule "if it break something it has to be reverted"
a mantra from which *many* other projects could learn

why?

because Linus is not acting like a blind butcher and aware of his
great responsibility which is the logical result of great power



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 24.03.2014 22:22, schrieb Peter Robinson:
> Interesting! You sent the email starting this thread a mere 4 days
> ago, two of those a weekend. You've not given it a chance to even go
> to FESCo meeting for discussion. Did you send it in the same way to
> the rest of the distros that depend, or are soon to depend on, systemd
> now SuSE, Arch, Debian, Ubuntu etc giving them no chance to
> discuss the impact before you unceremoniously tear a feature, for
> some, out?

be careful with criticism or you get killfild by Lennart



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 24.03.2014 21:51, schrieb Lennart Poettering:
> On Mon, 24.03.14 21:45, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> and that is the problem with you attitude
> 
> Okeydokey, as you wish, you are now in my killfile

so what - why should i case about beeing in the killfile
of people which can't stand criticism - other than you
i can and be not that thin-skinned to need a killfile



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 24.03.2014 21:32, schrieb Lennart Poettering:
> On Mon, 24.03.14 20:59, Reindl Harald (h.rei...@thelounge.net) wrote:
> 
>> Am 24.03.2014 20:27, schrieb Jóhann B. Guðmundsson:
>>> But certain people seem to rather want to drown Fedora in bureaucracy and 
>>> vague future proposals 
>>> and working groups instead of doing what needs to be done.
>>
>> no, certain people want to do something *useful* with their sytems and 
>> precious
>> time and not remove things and adopt changes with no good reason
>>
>> if you want to do worthful things go ahead as your QA job and clean systemd
>> especially the first one of the following list, they all hurt over months
>> and #1072368 comes back with the last systemd releases in Rawhide
> 
> You know, Harald, with your constant complaining you are just ensuring
> that people will ignore whatever you say

no more ignore is hardly possible
systemd in F19 was perfect
systemd in F20 is horrible from the view of a sysadmin

> For example, when I see a bug
> reported by you I put it at the very end of my TODO list, because I
> really don't want to deal with the constant complaints we are getting
> from you. 

if you would do your job better i would not have to complain

> You know, you are not dumb, and the stuff you post is often quite
> relevant to our work, but as long as you post this stuff the way you do
> the only thing you will achieve quickly is that we'll ignore what you
> say, and that you get moderated again on mailing lists like systemd-devel like
> you already got twice. That is a loss, since there are things in what
> you say that I find quite relevant. But jeesus, it's so frickin annoying
> to deal with you and your writings, you know that?

if it would not feel systemd upstream does not care what
happens left and right maybe the feedback would differnt

did you ever consider that?

>> https://bugzilla.redhat.com/show_bug.cgi?id=1072368
>> https://bugzilla.redhat.com/show_bug.cgi?id=1010572
>> https://bugzilla.redhat.com/show_bug.cgi?id=626477
>> https://bugzilla.redhat.com/show_bug.cgi?id=1047148
>> https://bugzilla.redhat.com/show_bug.cgi?id=1024379
> 
> Quite frankly, these all are fixed upstream

upstream does not help in case of Fedora

if the number one downstream distribution can't manage them
upstream should consider that thigs are not working properly

> or relatively harmless

define harmless

* frozen terminals in case of reboot remote servers is not harmless
* burry relevant messages in a permanent flood is not harmless

> things like where you'd prefer us to generate less log messages. Making
> such a fuss about these things is way over the top. Not a single one of
> these you posted is about actual functionality bugs not getting fixed
> upstream.

if you ever would have managed 10, 20, 30 servers where you do
things like distribute-command "cat /var/log/messages" and expect
to not get burried by irrelevant notices your point of view would
be different

the problem is that you insist in journald and filtering while
you refuse to understand larger setups

> Please try to understand that things like this don't get the highest
> priority on our TODO list. Also, you don't have the privilige of being
> entitled to get your own private bugs fixed immeidately, really

i understand that, but you need to understand the reaction because
in fact i do not take anybody serious not face things like
https://bugzilla.redhat.com/show_bug.cgi?id=1010572 after the
first boot - why? because that means the person never looks at
his logs, serious sysadmins do

> Yes, it would be nice if we fix them, but open source is really not 
> just about you demanding things and we giving it to you

you don't get the point

systemd in F19 is working perfect
systemd in F20 is horrible

i do not demand to introduce all that things which are the reason
for now i not consider to upgrade any production machine to F20

> It's a two way street, so instead of all the negative energy you spend 
> bitching about things, how about actually doing something really 
> constructive, 
> figuring out a patch or so, for the relevant things, and submitting that?

and that is the problem with you attitude

* making changes left and right
* not care about the impact of users
* demand users to chew the reuslt or fix it themslef




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 24.03.2014 20:30, schrieb Jóhann B. Guðmundsson:
>> Being at the bleeding edge of things also means deciding that
>> some things really should go, from time to time... Besides deprecating
>> old cruft like libwrap, this would also mean removing all the old crap
>> from comps "standard" that we still install by default (894110)...
> 
> For the record Fedora is not a bleeding edge distro anymore or first in 
> anything

maybe some people should consider the difference between "leading" and 
"bleeding"

smart: leading if things are ready
dumb:  bleeding for any price

if you think people are happily bleeding all the time you need a lot to learn
people accept bleeding for good reasons from time to time but not always with
no real benefit and if you want a distribution where users always bleed go
ahead but don't try to damage the way Fedora goes to become a serious
useable distribution over the time

if users bleed to much they dirft away before they die



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 24.03.2014 20:27, schrieb Jóhann B. Guðmundsson:
> But certain people seem to rather want to drown Fedora in bureaucracy and 
> vague future proposals 
> and working groups instead of doing what needs to be done.

no, certain people want to do something *useful* with their sytems and precious
time and not remove things and adopt changes with no good reason

if you want to do worthful things go ahead as your QA job and clean systemd
especially the first one of the following list, they all hurt over months
and #1072368 comes back with the last systemd releases in Rawhide

https://bugzilla.redhat.com/show_bug.cgi?id=1072368
https://bugzilla.redhat.com/show_bug.cgi?id=1010572
https://bugzilla.redhat.com/show_bug.cgi?id=626477
https://bugzilla.redhat.com/show_bug.cgi?id=1047148
https://bugzilla.redhat.com/show_bug.cgi?id=1024379




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