Request to take over orphaned python-mutagen
Hi all, as per [1], I'd like to take over the orphaned python-mutagen package. Let me know if there are any objections. Cheers, Michele [1] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure -- Michele Baldessarimich...@acksyn.org C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D -- 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: Workstation Product defaults to wide-open firewall
On Tue, 2014-12-09 at 17:29 +1030, William B wrote: I just happened to look at the firewalld default settings, and I was not amused when I noticed this: http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml port protocol=udp port=1025-65535/ port protocol=tcp port=1025-65535/ This firewall is a joke! ALL higher ports are wide open! I want to point out that for many home users, going into the future this is worse than it seems. Many of us are just thinking about the local network. Firewalld implements these rules not just for ipv4, but ipv6 too. If you have a low quality home router, that just lets ipv6 traffic in, you aren't just exposed to the whole network, but the whole internet. While ipv6 relies somewhat on well configured router firewalls, we cannot guarantee this. That is compromise. Of course there are untrustworthy LANs. However we shouldn't cripple functionality for users on their trusted lan because there may be few users in a LAN they don't trust. If you are in such a lan, then I'd expect to switch your firewall's zone. If the installer could do that automatically, it would be even better. regards, Nikos -- 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: [Test-Announce] Fedora 22 nightly compose 2014-12-08 nominated for testing
Dne 9.12.2014 v 04:06 Adam Williamson napsal(a): Just to recap, the idea here is that we try to get good coverage on the testing as early as possible, with the goal of giving the developers - especially the anaconda developers - longer to work on the critical issues. The earlier we identify and report the blocker issues, the earlier they can get fixed, the better the fixes should be (as they'll have more time to nail them down well), and the less time we should spend on emergency last minute test/hack/argue cycles. This may go along with a possible anaconda plan to freeze development around Alpha time, in order to reduce the amount of churn and regressions that occur post-Alpha, which would also make our lives easier and should hopefully mean that we'd spend a lot of time after Alpha reporting passes. But I think having the infrastructure for doing the early testing is useful whether or not that comes to pass. Hi Adam, This is very cool! Looking for F22 release exactly according to original schedule. Vít -- 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: Workstation Product defaults to wide-open firewall
Am 09.12.2014 um 10:08 schrieb Nikos Mavrogiannopoulos: On Tue, 2014-12-09 at 17:29 +1030, William B wrote: I just happened to look at the firewalld default settings, and I was not amused when I noticed this: http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml port protocol=udp port=1025-65535/ port protocol=tcp port=1025-65535/ This firewall is a joke! ALL higher ports are wide open! I want to point out that for many home users, going into the future this is worse than it seems. Many of us are just thinking about the local network. Firewalld implements these rules not just for ipv4, but ipv6 too. If you have a low quality home router, that just lets ipv6 traffic in, you aren't just exposed to the whole network, but the whole internet. While ipv6 relies somewhat on well configured router firewalls, we cannot guarantee this. That is compromise. Of course there are untrustworthy LANs. However we shouldn't cripple functionality for users on their trusted lan because there may be few users in a LAN they don't trust. you heard about notebooks, WLAN and public access points? If you are in such a lan, then I'd expect to switch your firewall's zone. If the installer could do that automatically, it would be even better you have nothing to expect from a ordinary user, otherwise the whole flaw would not exist for handholding reasons the user has to expect a by default secure configuration and if something can be expected at all than that people knowing their LAN sitch their firewall zone to a unsecure present and *not* the other direction 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: Best way to use zram in Fedora 21?
On Mon, Dec 08, 2014 at 11:55:07AM +0100, Dan Horák wrote: On Mon, 8 Dec 2014 11:36:47 +0100 Karel Zak k...@redhat.com wrote: BTW, util-linux v2.26 (f22) is going to contain new command zramctl(8) Karel $ zramctl --help Usage: lt-zramctl [options] device lt-zramctl -r device [...] lt-zramctl [options] -f | device -s size Options: -a, --algorithm lzo|lz4 compression algorithm to use can this work with HW accelerated compressors like the one in IBM Power CPUs? See eg. https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550/page/Build%20F17%20with%20Memory%20Compression Not sure, but it seems that zram currently supports only lzo and lz4 compression backends and boths are pure SW solutions. It does not use IMB nx-compression (kernel ./drivers/crypto/nx/nx-842.c). Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Best way to use zram in Fedora 21?
Am 09.12.2014 um 11:24 schrieb Karel Zak: On Mon, Dec 08, 2014 at 11:55:07AM +0100, Dan Horák wrote: On Mon, 8 Dec 2014 11:36:47 +0100 Karel Zak k...@redhat.com wrote: BTW, util-linux v2.26 (f22) is going to contain new command zramctl(8) $ zramctl --help Usage: lt-zramctl [options] device lt-zramctl -r device [...] lt-zramctl [options] -f | device -s size Options: -a, --algorithm lzo|lz4 compression algorithm to use can this work with HW accelerated compressors like the one in IBM Power CPUs? See eg. https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/W51a7ffcf4dfd_4b40_9d82_446ebc23c550/page/Build%20F17%20with%20Memory%20Compression Not sure, but it seems that zram currently supports only lzo and lz4 compression backends and boths are pure SW solutions. It does not use IMB nx-compression (kernel ./drivers/crypto/nx/nx-842.c) any chance to see util-linux v2.26 in F21? 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: Product defaults to wide-open firewall
- Original Message - Am Mon, 08 Dec 2014 23:31:42 + schrieb devel-requ...@lists.fedoraproject.org: Message: 7 Date: Mon, 08 Dec 2014 23:54:30 +0100 From: Alec Leamas leamas.a...@gmail.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: Workstation Product defaults to wide-open firewall Message-ID: 54862c26.9020...@gmail.com Content-Type: text/plain; charset=utf-8; format=flowed On 08/12/14 16:33, Matthew Miller wrote: On Mon, Dec 08, 2014 at 02:31:58PM +, Ian Malone wrote: There are three products: workstation, server, cloud. Workstation is the one for desktop use. That leaves server to aim for the traditional fedora user base, since cloud is (understandably) a very different thing. So if you want a desktop system with a security focus where do you look now? So, it's important to understand — here on the devel list, certainly — that these three are part of a marketing strategy, and in order for such a thing to be effective and not just fluffy talk, it does involve technical changes to match the plan. I have no problems with this. However, besides the technical/marketing trade-offs, here is also a process issue. Obviously, a lot of people were surprised by Kevin's finding that the workstation firewall was default open for ports 1024. Tracking this issue back we find [1] where the workstation group tried to just disable the firewall. This started some threads. FESCO rejected the change request. For me, this issue then disappeared from my radar. It seems that after FESCO turned down the wide-open system option the discussion was in the workstation list, where they ended up opening all user ports (?) and implemented this. When a lot of people are surprised, isn't that a sign of a process problem? Should we try to avoid surprises like this?. If so, how? (I'm not trying to be argumentative or to blame anyone; if my pidgin English gives that impression please ignore it). Cheers! --alec Is it possisible that the real reason for this decision from gnome was to fix a long outstanding bug in gnome-user-share? It wasn't. It caused problems with rhythmbox, gnome-user-share, UPnP/DLNA (both client and server), VNC sharing, and a number of other applications shipped in Fedora but not in the default set. This is something you could have discovered by reading the original thread instead of your feeble attempt at trolling GNOME. -- 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: Workstation Product defaults to wide-open firewall
- Original Message - As one who maintains a remix for journalists, I expect the default for a workstation should be that you mus* explicitly know what you are doing to open a port, and enable or start a service - the default release should have a minimum attack surface by design. You could disable networking in that case... As a result of this discussion I plan to modify my remix so that is the case - ports open by default in Fedora 21 Workstation will be closed in OSJourno. How do you plan on supporting your users that will want to share media, or services from their desktops/laptops? I'm on the fence over the ports below 1024, but I suspect those should be closed as well. Most ports below 1024 are already closed in Fedora Workstation, so there wouldn't be any changes there, which makes me think you didn't get the information about which ports are opened first-hand. You might want to read the original thread, and the accompanying spreadsheet: http://article.gmane.org/gmane.linux.redhat.fedora.desktop/9883/ Cheers On Mon, Dec 8, 2014 at 10:41 AM, Adam Jackson a...@redhat.com wrote: On Mon, 2014-12-08 at 18:40 +0100, Reindl Harald wrote: * vulnerable port open Yeah, see, this bit right here is the actual issue. Curiously, AV software on Other Operating Systems has had the ability to delegate this very policy decision to the user session for at least a decade, and yet nobody on this thread seems to have any desire to _write code_ to _fix the problem_. Instead we are treated to infinite spew about how nostalgic we are for a security model we learned in 1996. Sorry y'all, port-based security does not match reality's threat model. Let's be better than that. - ajax -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Twitter: http://twitter.com/znmeb; OSJourno: Robust Power Tools for Digital Journalists https://osjourno.com Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
- Original Message - sudo firewall-cmd --set-default-zone=FedoraServer That will limit it to SSH, DHCPv6 and cockpit Or use default zone Public, which swaps cockpit out and adds mDNS Or if you're Reindl Harald-level paranoid (no offense intended, Harald but you're the most paranoid sysadmin I know, even more than me): sudo firewall-cmd --set-default-zone=block It always amaze me why people that says it is easy to change de default, were not happy with: sudo firewall-cmd --set-default-zone=OpenZone instead of forcing the less secure one to eveyone. I also thought that the whole points of having Zones etc, was so that we could pick a different zone per network connection, so if I'm in the office or at home I can say use this zone, if I'm at a coffee shop I can pick a different one etc. Or was this consider too much UI for the normal user? Surely OSX has something to copy from, since they seem to define what a normal user expects. OSX has a firewall integration that I would rank as awful. It's not any better than what we had in Fedora 20 (blocking firewall and a tool to open up ports). -- 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: Workstation Product defaults to wide-open firewall
On Mon, 2014-12-08 at 16:30 +0100, Kevin Kofler wrote: Bastien Nocera wrote: If this had been discussed on this list, as it is supposed to, the objections would have come in much earlier. If you're interested in Workstation-specific features, you need to subscribe to desk...@lists.fedoraproject.org. This is where all Workstation-specific development occurs. The firewall configuration file in question will never be installed for non-Workstation users. signature.asc Description: This is a digitally signed message part -- 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: Workstation Product defaults to wide-open firewall
- Original Message - Stephen Gallagher wrote: Also, while I think it's been unclear in this thread, the main reason that the firewall GUI was taken out was because the Workstation guys want to design a more user-understandable one and include that directly (if I am remembering that conversation correctly). The current one is not terribly easy to understand (though it's certainly an improvement over s-c-firewall). Huh? Especially the last part really makes me go huh?. System-config- firewall is dead simple to use: I want service S to work, I check the box for service S if it's one of the common ones, or pick service S from the full /etc/services list if it's an uncommon one, or enter its port manually if it's some nonstandard service listening on an arbitrary port. I don't see how the UI can be any simpler. It can't be simpler, and that's the problem. There's no amount of lipstick that will make this UI palatable to the developers and users we want to attract to Fedora Workstation. So the way we make it simpler is by making it unnecessary. firewall-config is only complicated because firewalld is overly complex. Kevin Kofler -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Allow internet/network access based on binary -- ask user for permission if a binary wants to connect to the internet
- Original Message -
I only want certain binaries to be allowed network access.
For example, I want to allow the below binaries access to the internet:
/usr/lib64/firefox/firefox
/usr/lib/virtualbox/VirtualBox
/bin/yum (it seems to be done via python like /usr/bin/python /bin/yum
update -- so here obviously python is allowed network access only for
yum ('the binary'). This rule should not give python network access
for any other binaries/.py scripts etc.)
I want no other binary to be able to access the network.
It's not implementable, because you have no way to know that the
binary trying to access the network is what it says it is.
For now, at least. We'll certainly get something like that when
application sandboxing is implemented and deployed.
--
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: Workstation Product defaults to wide-open firewall
On Mon, 2014-12-08 at 10:49 -0500, Bastien Nocera wrote: If Reindl, Kevin or Tomas want to disagree with that, I'll give you a little exercise: Having just installed and updated my Fedora 20, I want to share a video in my home directory using UPnP/DLNA to my TV, using rygel for example. Document the steps necessary to achieve that. So unless anyone opposed to the firewall configuration change actually attempts this exercise, and comes up with a working alternative solution to the problem, I'm not sure there's much point in continuing the discussion. We are concerned with practical security -- keeping the user safe by anticipating the user's typical response to situations. But if you think the firewall configuration GUI in F20 existed for any purpose other than to completely disable the firewall, please take a reality check. signature.asc Description: This is a digitally signed message part -- 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: Workstation Product defaults to wide-open firewall
Hi, I also thought that the whole points of having Zones etc, was so that we could pick a different zone per network connection, /me too. so if I'm in the office or at home I can say use this zone, if I'm at a coffee shop I can pick a different one etc. Or was this consider too much UI for the normal user? Surely OSX has something to copy from, since they seem to define what a normal user expects. OSX has a firewall integration that I would rank as awful. It's not any better than what we had in Fedora 20 (blocking firewall and a tool to open up ports). Have a look at Windows then. Each time you hook a windows machine to a new network it asks what network this is. Used to be public, home, work. Recently they simplified that and kicked the home / work separation, so it's only public / non-public now. With some explanation along the lines of use public for hotspots, use home for your private network where you want share stuff. Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? Side Note: For the latter we need to cleanup the zones though. There are *way* to many to choose from, and the names suck big time. WTF is a Fedora$product zone? And wasn't that discussed before on this list? Why do we *still* have this mess? IMO there is simply no way around asking the user. Make sharing stuff easy (so you can watch your dnla-exported photo/video collection at your smart tv) is a reasonable request. But enabling that by allowing everybody fetch your private photo collection via dnla while you are surfing @ starbucks is a non-starter. cheers, Gerd PS: Seems windows can even identify different wired networks. I've switched my router recently, and windows re-asked what network I'm on. Probably they remember the mac address of the default gateway or something like that. -- 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: Workstation Product defaults to wide-open firewall
On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? We can — we just need someone to design and write it. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- 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: Product defaults to wide-open firewall
Am Tue, 09 Dec 2014 12:00:01 + schrieb devel-requ...@lists.fedoraproject.org: Message: 7 Date: Tue, 9 Dec 2014 05:54:46 -0500 (EST) From: Bastien Nocera bnoc...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: Product defaults to wide-open firewall Message-ID: 1627776125.20134262.1418122486256.javamail.zim...@redhat.com Content-Type: text/plain; charset=utf-8 Is it possisible that the real reason for this decision from gnome was to fix a long outstanding bug in gnome-user-share? It wasn't. It caused problems with rhythmbox, gnome-user-share, UPnP/DLNA (both client and server), VNC sharing, and a number of other applications shipped in Fedora but not in the default set. This is something you could have discovered by reading the original thread instead of your feeble attempt at trolling GNOME. I only asked a question. No need to offend people here in mailing list. Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Why should i troll gnome? -- 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: Workstation Product defaults to wide-open firewall
On Tue, Dec 09, 2014 at 12:35:23PM +0100, Michael Catanzaro wrote: We are concerned with practical security -- keeping the user safe by anticipating the user's typical response to situations. But if you think the firewall configuration GUI in F20 existed for any purpose other than to completely disable the firewall, please take a reality check. Unfortunately, this mirrors my experience, although many more folks cut-n-paste a command line to do the same thing (which they found on a random forum) rather than go through the GUI. - Solomon -- Solomon Peachy pizza at shaftnet dot org Delray Beach, FL ^^ (email/xmpp) ^^ Quidquid latine dictum sit, altum viditur. pgpV8dtktSyiB.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 9 December 2014 at 11:35, Michael Catanzaro mcatanz...@gnome.org wrote: On Mon, 2014-12-08 at 10:49 -0500, Bastien Nocera wrote: If Reindl, Kevin or Tomas want to disagree with that, I'll give you a little exercise: Having just installed and updated my Fedora 20, I want to share a video in my home directory using UPnP/DLNA to my TV, using rygel for example. Document the steps necessary to achieve that. So unless anyone opposed to the firewall configuration change actually attempts this exercise, and comes up with a working alternative solution to the problem, I'm not sure there's much point in continuing the discussion. Well, without access to Bastien's TV, home directory and router it's a bit difficult. Or is that the point? I haven't used rygel, is there any reason to believe difficulty doing this is not a problem with rygel in F20? We are concerned with practical security -- keeping the user safe by anticipating the user's typical response to situations. But if you think the firewall configuration GUI in F20 existed for any purpose other than to completely disable the firewall, please take a reality check. This isn't quite as bad as that other thing. Isn't the most persuasive argument, and in some cases it is worse (at least a user who's disabled the firewall knows they've done so). -- imalone http://ibmalone.blogspot.co.uk -- 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: Workstation Product defaults to wide-open firewall
On Tue, 2014-12-09 at 03:34 +0100, Kevin Kofler wrote: Because Fedora is aggressively marketing a Product with a major security vulnerability as its primary Product. To the extent that this is any argument at all: neither Ubuntu nor Debian enables a firewall. signature.asc Description: This is a digitally signed message part -- 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: Workstation Product defaults to wide-open firewall
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 09 Dec 2014 10:08:06 +0100 Nikos Mavrogiannopoulos n...@redhat.com wrote: On Tue, 2014-12-09 at 17:29 +1030, William B wrote: I just happened to look at the firewalld default settings, and I was not amused when I noticed this: http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml port protocol=udp port=1025-65535/ port protocol=tcp port=1025-65535/ This firewall is a joke! ALL higher ports are wide open! I want to point out that for many home users, going into the future this is worse than it seems. Many of us are just thinking about the local network. Firewalld implements these rules not just for ipv4, but ipv6 too. If you have a low quality home router, that just lets ipv6 traffic in, you aren't just exposed to the whole network, but the whole internet. While ipv6 relies somewhat on well configured router firewalls, we cannot guarantee this. That is compromise. Of course there are untrustworthy LANs. However we shouldn't cripple functionality for users on their trusted lan because there may be few users in a LAN they don't trust. If you are in such a lan, then I'd expect to switch your firewall's zone. If the installer could do that automatically, it would be even better. Can you personally, with 100% confidence tell me you completely understand the inner workings and firewall of your home? Your work? Have you pen tested them? Are you sure that they are open in some way you don't expect? If you answer no to any of these, you should probably reconsider how open your systems firewall is. I think that sacrificing security for convinence is not an option. Sometimes security can be hard, and the convinence look nice, but I want to strongly reiterate that the solution is not to open all ports and fool our users, but to create a secure by default os, that gives users control of that. If that means we need to face the hard truths and write some code to make a better firewalld ui, then so be it. - -- Sincerely, William Brown -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJUhvTSAAoJEO/EFteBqAmal44QAL3P0aVXGwoFzJbqpJI6EVjQ QvCHacmmgPpaCo0gs71SUdDWt0ku53ywCdPBatnEo/umLHCwRqS2UrgodGONnx8r bCAeyt6VADoxu50cYIQ/k/eHLz54fkr/QlkUq31wGzgM47lHASYpOmenIYHepCTD uEjt3SOeByPWyvoa5WOuKe7NkixvOutazYVhSqZvsPkgYaDqwzDi/MMP1ClMVNtm m5E4h0WYbiYVYmIvbkbfu60s12/jnVhfvMdyYSA3ZdGenjuz413EYTxpCtaLpyci om4YSN9D18vDGWrUMNeX56r2p1u3ZvL+a+fFRtWE7cJq4tEG8ix4/sr3wpR1JtPg xsU6+PdPW9RMGcbeeQ5BHc5w1SB6fWQvhEkx3XeLaeD5htEq3c+FqVaSlo8yQDMj /1x8QMwVDVmlbeA8vkvcwAsdO5jRok/R57Rj7r076v3laQp4QCVf9dURHuJ95pCP m3Ln2TguVOohV6jtMPtvCrqJQ1C1VUeSkCWTPo9kW4PgiN4O8w0EbBjB6M9B4GZB 0GjrKVJx4SPRK5sJfSL9HFSYEqvvudmGcij8swjjKldiVd/t4Y1bHyY7z4j2TvVp uNoN3/eZDR5rbkvlcBwoT82NStzpLEpPBIw3Znw7g2gp8jQLH5Xt7XM7Pa30v2Iv ZvR2kTt08xqjGzXeLYUi =6dr/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On Tue, 2014-12-09 at 07:27 +0100, Kevin Kofler wrote: Stephen Gallagher wrote: Also, while I think it's been unclear in this thread, the main reason that the firewall GUI was taken out was because the Workstation guys want to design a more user-understandable one and include that directly (if I am remembering that conversation correctly). The current one is not terribly easy to understand (though it's certainly an improvement over s-c-firewall). Huh? Especially the last part really makes me go huh?. System-config- firewall is dead simple to use: I want service S to work, I check the box for service S if it's one of the common ones, or pick service S from the full /etc/services list if it's an uncommon one, or enter its port manually if it's some nonstandard service listening on an arbitrary port. I don't see how the UI can be any simpler. firewall-config is only complicated because firewalld is overly complex. I'm a little puzzled that you decided to nitpick this one statement which was poorly phrased and ignore the rest of my email, but okay I'll bite. I meant to say that firewall-config is in general much improved over s-c-firewall, not that it was easy to understand. s-c-firewall only allowed *exactly* what you described above and left you to manually configure the firewall with the CLI if you needed anything more complicated than open this port on all interfaces. With firewall-config, it's possible to set up fairly common firewall configurations like: * Port forward between two interfaces, which is really useful with virtualizationFedoraWorkstation (default, active) interfaces: em1 virbr0 virbr0-nic wlp4s0 sources: services: dhcpv6-client dns freeipa-ldap freeipa-ldaps samba-client ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules: * Open this SMB port on these two multipath interfaces but not on this public interface or the management plane. And so on. And is firewalld overly complex? Sure. Firewalls *are* complex. Having used both firewall-cmd and iptables extensively over the years, I'd pick firewall-cmd any day. It's far easier to remember firewall-cmd --add-port=80/tcp than it is to remember iptables -I INPUT -p tcp --dport 80 -j ACCEPT (which I just had to Google to make sure I got it right, which I hadn't...). So for the really simple cases that s-c-firewall used to handle, it's still pretty darn easy. Moreover, it's *significantly* easier to see (and understand) the current firewall state on your system: firewall-cmd --list-all[-zones] On my system, this results in: FedoraWorkstation (default, active) interfaces: em1 virbr0 virbr0-nic wlp4s0 sources: services: dhcpv6-client dns freeipa-ldap freeipa-ldaps samba-client ssh ports: masquerade: no forward-ports: icmp-blocks: rich rules: (and yes, you may notice that I've elected to close the ports 1024 that are open by default in the Fedora Workstation zone, because I'm overly-paranoid and because I occasionally use non-Fedora software that I cannot fully trust not to open ports without me checking on it) Anyway, this post has admittedly gotten a bit rambling and off-topic, so I'll end it here. signature.asc Description: This is a digitally signed message part -- 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: Workstation Product defaults to wide-open firewall
On 8 December 2014 at 15:33, Matthew Miller mat...@fedoraproject.org wrote: On Mon, Dec 08, 2014 at 02:31:58PM +, Ian Malone wrote: There are three products: workstation, server, cloud. Workstation is the one for desktop use. That leaves server to aim for the traditional fedora user base, since cloud is (understandably) a very different thing. So if you want a desktop system with a security focus where do you look now? So, it's important to understand — here on the devel list, certainly — that these three are part of a marketing strategy, and in order for such a thing to be effective and not just fluffy talk, it does involve technical changes to match the plan. Right now, desktop system with a security focus for new users isn't a key part of that effort. I certainly don't dispute that user security and education are good goals, and I don't think anyone on the workstation team does either — it's just a matter of the steps we take to get there. So, if you're not in the target of that focus, where do you look? Well, you can certainly pick one of our other desktop spins, which have different firewall defaults. Currently, all the generic one, but I'd like to move to a model where spins have more freedom here too. We even have a proposal for a new spin focused on privacy and security — the Netizen Spin. (If you're interested, I think that could use additional contributors.) I was under the impression spins were to be phased out. I could be wrong, the discussion was about the time of the product proposal. Or, you can do what I do: start with Fedora Workstation and then configure it in a way that makes sense for my needs, or if you're deploying for users into a managed environment, use the tools the OS provides to preconfigure the system for whatever makes sense there. The thing is, while everyone in this discussion is probably capable of changing such defaults, it reflects a shift in priorities that leaves me wondering whether there'll be more such things that change and current users need to keep an eye on. If workstation doesn't want to appeal to current users why should they hang on and keep trying to tweak it to what they want? We now need to watch workstation to see what's going to happen on the desktop too. So the current list of things fedora users need to be subscribed to if they don't want to miss changes: users devel desktop (testing?) Where two of those are development lists where users aren't particularly welcome and on the other any discussion that involves what goes into the OS (or of an upcoming release the week before it's out) is declared off topic. -- imalone http://ibmalone.blogspot.co.uk -- 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: Workstation Product defaults to wide-open firewall
- Original Message - On 9 December 2014 at 11:35, Michael Catanzaro mcatanz...@gnome.org wrote: On Mon, 2014-12-08 at 10:49 -0500, Bastien Nocera wrote: If Reindl, Kevin or Tomas want to disagree with that, I'll give you a little exercise: Having just installed and updated my Fedora 20, I want to share a video in my home directory using UPnP/DLNA to my TV, using rygel for example. Document the steps necessary to achieve that. So unless anyone opposed to the firewall configuration change actually attempts this exercise, and comes up with a working alternative solution to the problem, I'm not sure there's much point in continuing the discussion. Well, without access to Bastien's TV, home directory and router it's a bit difficult. Or is that the point? Another laptop with Fedora running on it would just increase the difficulty, but you can use that, or a set-top box with DLNA support. The router can be any stock router, and again, it doesn't have any impact on the difficulty of putting the above in place, as the problem is solely on the sharing service's side. I haven't used rygel, is there any reason to believe difficulty doing this is not a problem with rygel in F20? It isn't a problem of rygel, it's a problem of a static firewall with dynamic services. It impacts all services/applications that use dynamic ports. We are concerned with practical security -- keeping the user safe by anticipating the user's typical response to situations. But if you think the firewall configuration GUI in F20 existed for any purpose other than to completely disable the firewall, please take a reality check. This isn't quite as bad as that other thing. Isn't the most persuasive argument, and in some cases it is worse (at least a user who's disabled the firewall knows they've done so). And then we can blame the user for not knowing what they just did. If they managed to get to that point... Absent from this thread are also all the people that thanked me personally, or through colleagues, about the new defaults that were finally usable, yet avoided the problems of over-sharing when not at home, or in insecure Wi-Fi networks. -- 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: Workstation Product defaults to wide-open firewall
- Original Message - On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? We can — we just need someone to design and write it. A design for something that we don't want to implement. This was one of the options when implementing the feature, one that we didn't pursue. We chose instead to use user intent as a way to do this. If you start sharing something on a network, then we consider it safe to share. If you connect to a public unencrypted Wi-Fi, you won't have the option to. If you connect to an encrypted Wi-Fi where sharing your holiday photos isn't acceptable then it won't, because you didn't ask it to in the first place. -- 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: Workstation Product defaults to wide-open firewall
Am 09.12.2014 um 14:16 schrieb Bastien Nocera: On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? We can — we just need someone to design and write it. A design for something that we don't want to implement. and that is the point - you do not want and care because you seem to think users are too stupid to make their own decisions - you know what Linus said to that in direction of GNOME? This was one of the options when implementing the feature, one that we didn't pursue. We chose instead to use user intent as a way to do this. If you start sharing something on a network, then we consider it safe to share. the problem is that you don't know *who* or *what* opened the port If you connect to a public unencrypted Wi-Fi, you won't have the option to. If you connect to an encrypted Wi-Fi where sharing your holiday photos isn't acceptable then it won't, because you didn't ask it to in the first place besides suspend / move machine a sane firewall design (sadly Windows has that in the meantime) is that if i open a port in my homenetwork, supsend the machine and wake it up in a foreign network ports are closed until i decide to open them there too, but Fedora goes the easy way who cares how and why as long things appear to work *who* told you that people don't share things *unintentional* by a wrong click which is *not* a problem until you decide to open ports 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
[PkgDB] psabata:perl-asa watchcommits set to Approved
user: psabata set for psabata acl: watchcommits of package: perl-asa from: Approved to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-asa -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] psabata:perl-asa approveacls set to Approved
user: psabata set for psabata acl: approveacls of package: perl-asa from: Approved to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-asa -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] psabata:perl-asa commit set to Approved
user: psabata set for psabata acl: commit of package: perl-asa from: Approved to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-asa -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] psabata:perl-asa watchbugzilla set to Approved
user: psabata set for psabata acl: watchbugzilla of package: perl-asa from: Approved to: Approved on branch: epel7 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-asa -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Workstation Product defaults to wide-open firewall
- Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 09 Dec 2014 10:08:06 +0100 Nikos Mavrogiannopoulos n...@redhat.com wrote: On Tue, 2014-12-09 at 17:29 +1030, William B wrote: I just happened to look at the firewalld default settings, and I was not amused when I noticed this: http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml port protocol=udp port=1025-65535/ port protocol=tcp port=1025-65535/ This firewall is a joke! ALL higher ports are wide open! I want to point out that for many home users, going into the future this is worse than it seems. Many of us are just thinking about the local network. Firewalld implements these rules not just for ipv4, but ipv6 too. If you have a low quality home router, that just lets ipv6 traffic in, you aren't just exposed to the whole network, but the whole internet. While ipv6 relies somewhat on well configured router firewalls, we cannot guarantee this. That is compromise. Of course there are untrustworthy LANs. However we shouldn't cripple functionality for users on their trusted lan because there may be few users in a LAN they don't trust. If you are in such a lan, then I'd expect to switch your firewall's zone. If the installer could do that automatically, it would be even better. Can you personally, with 100% confidence tell me you completely understand the inner workings and firewall of your home? Your work? Have you pen tested them? Are you sure that they are open in some way you don't expect? If you answer no to any of these, you should probably reconsider how open your systems firewall is. I think that sacrificing security for convinence is not an option. Sometimes security can be hard, and the convinence look nice, but I want to strongly reiterate that the solution is not to open all ports and fool our users, but to create a secure by default os, that gives users control of that. If that means we need to face the hard truths and write some code to make a better firewalld ui, then so be it. To do that, you would need to understand that security isn't a black and white thing, it's different shades of gray. You also didn't consider privacy into the mix, which is related to security, but different from it. If by opening up some ports that would have hampered the user, rather than protect them[1], we avoid the users disabling the firewall, and exposing security critical services (such as exposing rpcbind, or ntpd, or any other root service), then it's a win for me. [1]: I haven't seen anything but arm-flailing on that issue. If somebody wants to go into details about what a server running inside the user's session would be able to do that a client wouldn't be able to, feel free. -- 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: Workstation Product defaults to wide-open firewall
Am 09.12.2014 um 14:23 schrieb Bastien Nocera: [1]: I haven't seen anything but arm-flailing on that issue. If somebody wants to go into details about what a server running inside the user's session would be able to do that a client wouldn't be able to, feel free. you realize the difference between a open port found by a network scan in a public WLAN by any other client and a active outgoing connection to specific machines? you realize that a security relevant bug in a service available over the network may execute *any code* not intented by the running application 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
[PkgDB] psabata:perl-Cache-FastMmap watchcommits set to Approved
user: psabata set for psabata acl: watchcommits of package: perl-Cache-FastMmap from: Approved to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Cache-FastMmap -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Workstation Product defaults to wide-open firewall
- Original Message - Am 09.12.2014 um 14:16 schrieb Bastien Nocera: On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? We can — we just need someone to design and write it. A design for something that we don't want to implement. and that is the point - you do not want and care because you seem to think users are too stupid to make their own decisions I never used the word stupid and I don't equate not knowing about IP ports and firewalls to stupidity. - you know what Linus said to that in direction of GNOME? This was one of the options when implementing the feature, one that we didn't pursue. We chose instead to use user intent as a way to do this. If you start sharing something on a network, then we consider it safe to share. the problem is that you don't know *who* or *what* opened the port And with the current scheme, I don't need to know either. If you connect to a public unencrypted Wi-Fi, you won't have the option to. If you connect to an encrypted Wi-Fi where sharing your holiday photos isn't acceptable then it won't, because you didn't ask it to in the first place besides suspend / move machine If you suspend or disconnect from the network, sharing is disabled. If you connect to another network, sharing is disabled (unless it was previously enabled, by the user). It's also possible to disable sharing for networks you're not connected to. a sane firewall design (sadly Windows has that in the meantime) is that if i open a port in my homenetwork, supsend the machine and wake it up in a foreign network ports are closed until i decide to open them there too, but Fedora goes the easy way who cares how and why as long things appear to work *who* told you that people don't share things *unintentional* by a wrong click which is *not* a problem until you decide to open ports Making people click twice isn't a security feature. If the user intended on Sharing something, which is likely if you need to go to the Sharing settings to do so, why do you try to second guess him/her by having a 2nd level of question, completely disconnected from the original request. I could add a are you sure you want to share this dialogue, which would have the same amount of security as your solution... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] psabata:perl-Catalyst-Plugin-SubRequest commit set to Approved
user: psabata set for psabata acl: commit of package: perl-Catalyst-Plugin-SubRequest from: Approved to: Approved on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-Plugin-SubRequest -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] psabata:perl-Catalyst-Plugin-Session-Store-FastMmap set point of contact to: psabata
user: psabata changed point of contact of package: perl-Catalyst-Plugin-Session-Store-FastMmap from: orphan to: psabata on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-Plugin-Session-Store-FastMmap -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] psabata:perl-Catalyst-Plugin-Session-State-Cookie set point of contact to: psabata
user: psabata changed point of contact of package: perl-Catalyst-Plugin-Session-State-Cookie from: orphan to: psabata on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-Plugin-Session-State-Cookie -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Workstation Product defaults to wide-open firewall
- Original Message - Am 09.12.2014 um 14:23 schrieb Bastien Nocera: [1]: I haven't seen anything but arm-flailing on that issue. If somebody wants to go into details about what a server running inside the user's session would be able to do that a client wouldn't be able to, feel free. you realize the difference between a open port found by a network scan in a public WLAN by any other client and a active outgoing connection to specific machines? you realize that a security relevant bug in a service available over the network may execute *any code* not intented by the running application at all? So the solution isn't to close ports, but not run services in contexts where it isn't safe to do so. This is what we implemented. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] psabata:perl-Catalyst-View-TT set point of contact to: psabata
user: psabata changed point of contact of package: perl-Catalyst-View-TT from: orphan to: psabata on branch: el6 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Catalyst-View-TT -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Product defaults to wide-open firewall
- Original Message - Am Tue, 09 Dec 2014 12:00:01 + schrieb devel-requ...@lists.fedoraproject.org: Message: 7 Date: Tue, 9 Dec 2014 05:54:46 -0500 (EST) From: Bastien Nocera bnoc...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Subject: Re: Product defaults to wide-open firewall Message-ID: 1627776125.20134262.1418122486256.javamail.zim...@redhat.com Content-Type: text/plain; charset=utf-8 Is it possisible that the real reason for this decision from gnome was to fix a long outstanding bug in gnome-user-share? It wasn't. It caused problems with rhythmbox, gnome-user-share, UPnP/DLNA (both client and server), VNC sharing, and a number of other applications shipped in Fedora but not in the default set. This is something you could have discovered by reading the original thread instead of your feeble attempt at trolling GNOME. I only asked a question. No need to offend people here in mailing list. Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Why should i troll gnome? You shouldn't, but did anyway. I think it was pretty clear from the rest of the discussion that the problem didn't only impact gnome-user-share. I'm not sure what other kind of answers you were expecting from the way you labelled your question. -- 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: Workstation Product defaults to wide-open firewall
On Mon, 2014-12-08 at 16:41 +0100, Kevin Kofler wrote: So you rather implement the type of OS that just always assumes Yes without even asking? Because that's what the current firewall rules do (between quotes because it can hardly be called a firewall in that state). How's that more secure than asking? I think the prevailing opinion of the GNOME safety team is that yes/no or allow/disallow dialogs are unacceptable. These just train the user to click yes. Certainly, we are not going to ask for each app that wants to access the network. Instead, we pick a reasonable default and stick with it. The default for an invalid TLS certificate should be to fail, no exceptions, since we know that a user clicking Yes is almost always picking the wrong option. The default for a network service is Allow, since Deny would almost always be the wrong option. What we do need is a better story for helping the user pick a reasonable firewall zone. Home/Work/Coffeeshop is a simple question that's difficult for users to get wrong. The users who don't know about firewall ports will not need to open them up at all. This is not true, or we would not have changed the firewall defaults and we would not be having this conversation. Back to Bastien's use case: I want to share a video in my home directory using UPnP/DLNA to my TV, using rygel for example. This is a simple requirement, and we're plainly unwilling to revert to the F20 settings as it would break this use case. So your challenge is to find an alternative default that supports it: then we'll have more to talk about. signature.asc Description: This is a digitally signed message part -- 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: Workstation Product defaults to wide-open firewall
On Mon, 2014-12-08 at 18:56 -0800, M. Edward (Ed) Borasky wrote: is Workstation the only Fedora-branded release with those ports open? Yes signature.asc Description: This is a digitally signed message part -- 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: Workstation Product defaults to wide-open firewall
Am 09.12.2014 um 14:32 schrieb Bastien Nocera: Am 09.12.2014 um 14:23 schrieb Bastien Nocera: [1]: I haven't seen anything but arm-flailing on that issue. If somebody wants to go into details about what a server running inside the user's session would be able to do that a client wouldn't be able to, feel free. you realize the difference between a open port found by a network scan in a public WLAN by any other client and a active outgoing connection to specific machines? you realize that a security relevant bug in a service available over the network may execute *any code* not intented by the running application at all? So the solution isn't to close ports, but not run services in contexts where it isn't safe to do so. This is what we implemented *boah* * you do not know what is running on a endusers machine * you do not know when soemthing is running why it is * you can not gurantee that just by a bug something won't run * you can guarantee *nothing at all* the only thing you can know is the default setup you ship if you think your responsibility ends with what you ship as defaults the you can't pretend you create a operating system at all call it appliance and anything the user does with or without understanding the possible impact is unsupported 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: Workstation Product defaults to wide-open firewall
On Tue, Dec 09, 2014 at 01:11:33PM +, Ian Malone wrote: have a proposal for a new spin focused on privacy and security — the Netizen Spin. (If you're interested, I think that could use additional contributors.) I was under the impression spins were to be phased out. I could be wrong, the discussion was about the time of the product proposal. That's wrong; the clear outcome of that discussion was that we want to keep them, and provide more flexiblity and opportunity for spins maintainers as well. The thing is, while everyone in this discussion is probably capable of changing such defaults, it reflects a shift in priorities that leaves me wondering whether there'll be more such things that change and current users need to keep an eye on. If workstation doesn't want to So, again, I think that the idea that this reflects a drastic shift in priorities isn't accurate, and with disagreement on that axiom, the rest of the argument is just people talking past each other. Everyone wants Fedora to succeed. Everyone wants free software to win. Everyone wants better privacy and security for our users. It's a basic fact that Workstation WG chose this as the best path to get there -- whether or not you agree, let's work from a basic assumption of trust that we're all on the same side here. Everyone knows that there are improvements to be made, but it's _not_ an easy problem. Contributions are welcome towards making that better for F22 and beyond. (Use cases. Design mockups. Code) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] psabata:perl-App-Daemon watchcommits set to Approved
user: psabata set for psabata acl: watchcommits of package: perl-App-Daemon from: Approved to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-App-Daemon -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] psabata:perl-App-Daemon commit set to Approved
user: psabata set for psabata acl: commit of package: perl-App-Daemon from: Approved to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-App-Daemon -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[PkgDB] psabata:perl-App-Daemon watchbugzilla set to Approved
user: psabata set for psabata acl: watchbugzilla of package: perl-App-Daemon from: Approved to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-App-Daemon -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Workstation Product defaults to wide-open firewall
On Tue, Dec 09, 2014 at 02:41:08PM +0100, Michael Catanzaro wrote: is Workstation the only Fedora-branded release with those ports open? Yes Well, no. Fedora Cloud doesn't include any iptables rules by default. (The assumption is that it'll be run in a cloud environment with security groups at a higher layer.) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] psabata:perl-Cache watchcommits set to Approved
user: psabata set for psabata acl: watchcommits of package: perl-Cache from: Approved to: Approved on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Cache -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Workstation Product defaults to wide-open firewall
On 9 December 2014 at 13:39, Michael Catanzaro mcatanz...@gnome.org wrote: So your challenge is to find an alternative default that supports it. I'd go even further. I don't think the people writing the vast number of lengthy posts on this thread actually want to *use* workstation, with the possible exception of Bastien who's having to defend something he shouldn't have to. Reindl probably should just use the server spin, or be prepared to actually configure his box to do what he wants to be 100% paranoid and unusable for anything less than a technical user. If you don't like what workstation has decided to do, use another target, or a different distro entirely (like CentOS). If you want to change how workstation is designed, join the working group and please actually talk to people there. I think it's misguided to think that hurling insults here is going to achieve change. I think a lot of people also need to remember that workstation isn't built for them, and that's okay. If you know how to configure iptables then that's fine, but I'm happy to admit I don't, and normally just switch off the firewall entirely so I can get stuff done. F21 will be more secure for me, not less. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[PkgDB] psabata:perl-Gearman-Client-Async set point of contact to: psabata
user: psabata changed point of contact of package: perl-Gearman-Client-Async from: orphan to: psabata on branch: el5 To make changes to this package see: https://admin.fedoraproject.org/pkgdb/package/perl-Gearman-Client-Async -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Workstation Product defaults to wide-open firewall
On Mon, 2014-12-08 at 17:08 -0430, Robert Marcano wrote: Adding to that, this decision bring me memories to the awful old case when someone decided that the install anything from the repositories was permitted to any user on the system by default, that was reverted with an update because of the outrage That IS still permitted in both Fedora 20 and Fedora 21. No authentication is required to install via PackageKit (e.g. with GNOME Software for apps, or pkcon for packages). signature.asc Description: This is a digitally signed message part -- 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: Workstation Product defaults to wide-open firewall
On 12/09/2014 08:53 AM, Reindl Harald wrote: Am 09.12.2014 um 14:16 schrieb Bastien Nocera: On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? We can — we just need someone to design and write it. A design for something that we don't want to implement. and that is the point - you do not want and care because you seem to think users are too stupid to make their own decisions - you know what Linus said to that in direction of GNOME? This was one of the options when implementing the feature, one that we didn't pursue. We chose instead to use user intent as a way to do this. If you start sharing something on a network, then we consider it safe to share. the problem is that you don't know *who* or *what* opened the port Exactly, I think some people think we already reached the utopic world, when everyone install FLOSS applications from the repositories, and no one uses closed source applications, or worse where all sharing is done using GNOME control panel, and there isn't applications that doesn't take into account the GNOME way of doing things. What I see frequently are applications that are installed from outside the Fedora repositories, that can be forced to behave like Fedora packaging rules, with secure defaults before sharing, being installed and the user that don't know much about firewall settings but understand that the firewall is active, then think: I feel secure because I know the firewall is blocking external requests. and then in that utopic world things fail, for example, Fedora packaging rules prefer that packages are installed with sensitive defaults, I reported a bug about all cron email output being sent by default and it was discarded as a security bug (pulled by an update) https://bugzilla.redhat.com/show_bug.cgi?id=1157727 https://bugzilla.redhat.com/show_bug.cgi?id=1158493 https://lists.fedoraproject.org/pipermail/devel/2014-October/203781.html This is no open port, but shows that packages can have bugs and something that is closed by default today, can in the future be pulled as an update and start sharing things. Those are bugs, true, but the idea of opening the firewall entirely defeats the measure of defense already in place. To me it sounds like disabling SELinux on workstation because people find it difficult and decide to disable it instead. The problem that is being tried to solve is that people choose to disable the firewall, Why not add a simple option to the GNOME sharing tools to change the firewall zone to this one where ports 1024 are open when the user decide to share something. with the possibility to selecting no for those people that only want to open the only the needed ports? Note: I hope to not be called a troll here (joke, someone will understand) If you connect to a public unencrypted Wi-Fi, you won't have the option to. If you connect to an encrypted Wi-Fi where sharing your holiday photos isn't acceptable then it won't, because you didn't ask it to in the first place besides suspend / move machine a sane firewall design (sadly Windows has that in the meantime) is that if i open a port in my homenetwork, supsend the machine and wake it up in a foreign network ports are closed until i decide to open them there too, but Fedora goes the easy way who cares how and why as long things appear to work *who* told you that people don't share things *unintentional* by a wrong click which is *not* a problem until you decide to open ports -- 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: Workstation Product defaults to wide-open firewall
On 12/09/2014 09:20 AM, Michael Catanzaro wrote: On Mon, 2014-12-08 at 17:08 -0430, Robert Marcano wrote: Adding to that, this decision bring me memories to the awful old case when someone decided that the install anything from the repositories was permitted to any user on the system by default, that was reverted with an update because of the outrage That IS still permitted in both Fedora 20 and Fedora 21. No authentication is required to install via PackageKit (e.g. with GNOME Software for apps, or pkcon for packages). No this is only for users that at install time or later are added as Administrators, that old bug (I saw on another email that was on Fedora 12) was for everyone. the excuse, we have no implemented that user distinction, so for now it will be open to all, or something like that. Sounds to me like the kind of defense to this change: No one has implemented something better, so we will open ports I think that when we fall for the disable security measures because we have no better UI for now, We will never have a better UI because no one will build one for something that is already open -- 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: Workstation Product defaults to wide-open firewall
- Original Message - Am 09.12.2014 um 14:32 schrieb Bastien Nocera: Am 09.12.2014 um 14:23 schrieb Bastien Nocera: [1]: I haven't seen anything but arm-flailing on that issue. If somebody wants to go into details about what a server running inside the user's session would be able to do that a client wouldn't be able to, feel free. you realize the difference between a open port found by a network scan in a public WLAN by any other client and a active outgoing connection to specific machines? you realize that a security relevant bug in a service available over the network may execute *any code* not intented by the running application at all? So the solution isn't to close ports, but not run services in contexts where it isn't safe to do so. This is what we implemented *boah* * you do not know what is running on a endusers machine * you do not know when soemthing is running why it is * you can not gurantee that just by a bug something won't run * you can guarantee *nothing at all* the only thing you can know is the default setup you ship And the end user's responsibility is to know all that? To know the implementation details of services, what ports they open, and why? Maybe we should add IP based network knowledge to the install requirements if you think that's the case. And you're completely correct that we don't have bug free software or packaging. Which is why, still on my TODO list, is integrating a regression suite to make sure that services and applications don't start serving services when they shouldn't. That's dependent on Taskotron being deployed which is why it wasn't already done. You're more than welcome helping with that. if you think your responsibility ends with what you ship as defaults the you can't pretend you create a operating system at all call it appliance and anything the user does with or without understanding the possible impact is unsupported It's not an appliance. You can get back your F20 configuration you so liked with a single command-line. Which you know about. Which I wouldn't expect any user to have to know to do the opposite. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
rawhide report: 20141209 changes
Compose started at Tue Dec 9 05:15:02 UTC 2014 Broken deps for i386 -- [3Depict] 3Depict-0.0.16-3.fc22.i686 requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [bibletime] bibletime-2.10.1-4.fc22.i686 requires libsword-1.7.3.so [cab] cab-0.1.9-12.fc22.i686 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14 [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [kaccessible] kaccessible-libs-14.11.97-1.fc22.i686 requires kdelibs4(x86-32) = 0:14.11.97 [kosmtik] kosmtik-0.0.9-2.fc22.noarch requires font(firasansotlight) kosmtik-0.0.9-2.fc22.noarch requires font(firasansot) [nwchem] nwchem-openmpi-6.3.2-11.fc21.i686 requires libmpi_usempi.so.1 [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.i686 requires libmongoclient.so uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.i686 requires libmongoclient.so [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-utils-20140510-2.fc22.i686 requires libpolyclipping.so.16 [wine] wine-1.7.32-1.fc22.i686 requires mingw32-wine-gecko = 0:2.34 [xiphos] xiphos-3.2.2-2.fc22.i686 requires libsword-1.7.3.so Broken deps for x86_64 -- [3Depict] 3Depict-0.0.16-3.fc22.x86_64 requires libmgl.so.7.2.0()(64bit) [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [bibletime] bibletime-2.10.1-4.fc22.x86_64 requires libsword-1.7.3.so()(64bit) [cab] cab-0.1.9-12.fc22.x86_64 requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.x86_64 requires libval-threads.so.14()(64bit) dnssec-check-1.14.0.1-4.fc20.x86_64 requires libsres.so.14()(64bit) [glances] glances-2.1.2-2.fc22.noarch requires python-psutil = 0:2.0.0 [kaccessible] kaccessible-libs-14.11.97-1.fc22.i686 requires kdelibs4(x86-32) = 0:14.11.97 kaccessible-libs-14.11.97-1.fc22.x86_64 requires kdelibs4(x86-64) = 0:14.11.97 [kosmtik] kosmtik-0.0.9-2.fc22.noarch requires font(firasansotlight) kosmtik-0.0.9-2.fc22.noarch requires font(firasansot) [nwchem] nwchem-openmpi-6.3.2-11.fc21.x86_64 requires libmpi_usempi.so.1()(64bit) [openstack-neutron-gbp] openstack-neutron-gbp-2014.2-0.2.acb85f0git.fc22.noarch requires openstack-neutron = 0:2014.2 [pam_mapi] pam_mapi-0.2.0-3.fc22.i686 requires libmapi.so.0 pam_mapi-0.2.0-3.fc22.x86_64 requires libmapi.so.0()(64bit) [python-selenium] python3-selenium-2.43.0-1.fc22.noarch requires python3-rdflib [rubygem-wirb] rubygem-wirb-1.0.3-2.fc21.noarch requires rubygem(paint) 0:0.9 [shogun] shogun-doc-3.2.0.1-0.27.git20140804.96f3cf3.fc22.noarch requires shogun-data = 0:0.8.1-0.18.git20140804.48a1abb.fc22 [uwsgi] uwsgi-plugin-gridfs-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) uwsgi-stats-pusher-mongodb-2.0.7-2.fc22.x86_64 requires libmongoclient.so()(64bit) [vfrnav] vfrnav-20140510-2.fc22.i686 requires libpolyclipping.so.16 vfrnav-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) vfrnav-utils-20140510-2.fc22.x86_64 requires libpolyclipping.so.16()(64bit) [wine] wine-1.7.32-1.fc22.i686 requires mingw32-wine-gecko = 0:2.34 wine-1.7.32-1.fc22.x86_64 requires mingw64-wine-gecko = 0:2.34 wine-1.7.32-1.fc22.x86_64 requires mingw32-wine-gecko = 0:2.34 [xiphos] xiphos-3.2.2-2.fc22.x86_64 requires libsword-1.7.3.so()(64bit) Broken deps for armhfp -- [3Depict] 3Depict-0.0.16-3.fc22.armv7hl requires libmgl.so.7.2.0 [Sprog] Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0) [avro] avro-mapred-1.7.5-9.fc22.noarch requires hadoop-mapreduce avro-mapred-1.7.5-9.fc22.noarch requires hadoop-client [bibletime] bibletime-2.10.1-4.fc22.armv7hl requires libsword-1.7.3.so [cab] cab-0.1.9-12.fc22.armv7hl requires cabal-dev [dnssec-check] dnssec-check-1.14.0.1-4.fc20.armv7hl requires libval-threads.so.14 dnssec-check-1.14.0.1-4.fc20.armv7hl requires libsres.so.14 [glances] glances-2.1.2-2.fc22.noarch requires
Re: Workstation Product defaults to wide-open firewall
On Tue, 2014-12-09 at 14:41 +0100, Michael Catanzaro wrote: On Mon, 2014-12-08 at 18:56 -0800, M. Edward (Ed) Borasky wrote: is Workstation the only Fedora-branded release with those ports open? Yes No, actually. The Fedora Cloud ships with no firewall at all (but that's because it's expected that in cloud computing environments, that's handled at the cloud infrastructure level, not the individual node). However, Fedora Server and the other spins have much more conservative default firewall configurations. signature.asc Description: This is a digitally signed message part -- 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: Workstation Product defaults to wide-open firewall
On 12/09/2014 09:27 AM, Robert Marcano wrote: What I see frequently are applications that are installed from outside the Fedora repositories, that can be forced to behave like Fedora packaging rules, with secure defaults before sharing, being installed and the user that don't know much about firewall settings but understand that the firewall is active, then think: I feel secure because I know the firewall is blocking external requests. that should be a that can't be forced not can ... This is no open port, but shows that packages can have bugs and something that is closed by default today, can in the future be pulled as an update and start sharing things. Those are bugs, true, but the idea of opening the firewall entirely defeats the measure of defense already in place. To me it sounds like disabling SELinux on workstation because people find it difficult and decide to disable it instead. and before someone say that SELinux is a server thing that should not bother user, Never had user NetworkManager openvpn plugin that require certificates to have the corresponding SELinux label inside ~/.cert, and than when you move you backed up certificates, they will not be read because move doesn't change labels. I can make the same assumption that SELinux is difficult and the user always prefer to disable it -- 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: Workstation Product defaults to wide-open firewall
On 12/09/2014 08:50 AM, Richard Hughes wrote: On 9 December 2014 at 13:39, Michael Catanzaro mcatanz...@gnome.org wrote: So your challenge is to find an alternative default that supports it. I'd go even further. I don't think the people writing the vast number of lengthy posts on this thread actually want to *use* workstation, with the possible exception of Bastien who's having to defend something he shouldn't have to. Reindl probably should just use the server spin, or be prepared to actually configure his box to do what he wants to be 100% paranoid and unusable for anything less than a technical user. If you don't like what workstation has decided to do, use another target, or a different distro entirely (like CentOS). If you want to change how workstation is designed, join the working group and please actually talk to people there. I think it's misguided to think that hurling insults here is going to achieve change. I think a lot of people also need to remember that workstation isn't built for them, and that's okay. If you know how to configure iptables then that's fine, but I'm happy to admit I don't, and normally just switch off the firewall entirely so I can get stuff done. F21 will be more secure for me, not less. Ok, so what product/spin am I supposed to use? I'm a RHEL sysadmin but I use Fedora on my desktop laptop. I expect the firewall to be on so when I evaluate a new piece of software or do a bit of network development I don't inadvertently increase my exposure. I also expect things to work with the minimum amount of fuss. So it looks like my choices boil down to: * Use the workstation project and spend a bunch of time locking it down to what would be reasonable default for the networks I use -- and hope I don't miss anything. * Use the server product and manually configure all of the workstation stuff so I get a usable system Neither of those choices seem reasonable to me, especially compared to the status quo: a fully configured workstation where I open new ports as I increase functionality. -- 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: Workstation Product defaults to wide-open firewall
On Tue, 2014-12-09 at 08:23 -0500, Bastien Nocera wrote: - Original Message - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 09 Dec 2014 10:08:06 +0100 Nikos Mavrogiannopoulos n...@redhat.com wrote: On Tue, 2014-12-09 at 17:29 +1030, William B wrote: I just happened to look at the firewalld default settings, and I was not amused when I noticed this: http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml port protocol=udp port=1025-65535/ port protocol=tcp port=1025-65535/ This firewall is a joke! ALL higher ports are wide open! I want to point out that for many home users, going into the future this is worse than it seems. Many of us are just thinking about the local network. Firewalld implements these rules not just for ipv4, but ipv6 too. If you have a low quality home router, that just lets ipv6 traffic in, you aren't just exposed to the whole network, but the whole internet. While ipv6 relies somewhat on well configured router firewalls, we cannot guarantee this. That is compromise. Of course there are untrustworthy LANs. However we shouldn't cripple functionality for users on their trusted lan because there may be few users in a LAN they don't trust. If you are in such a lan, then I'd expect to switch your firewall's zone. If the installer could do that automatically, it would be even better. Can you personally, with 100% confidence tell me you completely understand the inner workings and firewall of your home? Your work? Have you pen tested them? Are you sure that they are open in some way you don't expect? If you answer no to any of these, you should probably reconsider how open your systems firewall is. I think that sacrificing security for convinence is not an option. Sometimes security can be hard, and the convinence look nice, but I want to strongly reiterate that the solution is not to open all ports and fool our users, but to create a secure by default os, that gives users control of that. If that means we need to face the hard truths and write some code to make a better firewalld ui, then so be it. To do that, you would need to understand that security isn't a black and white thing, it's different shades of gray. You also didn't consider privacy into the mix, which is related to security, but different from it. If by opening up some ports that would have hampered the user, rather than protect them[1], we avoid the users disabling the firewall, and exposing security critical services (such as exposing rpcbind, or ntpd, or any other root service), then it's a win for me. [1]: I haven't seen anything but arm-flailing on that issue. If somebody wants to go into details about what a server running inside the user's session would be able to do that a client wouldn't be able to, feel free. Just to answer that, you're assuming that the only risk is to the local machine. A service running in a local user session can be opening a port for a command-and-control server somewhere out on the internet to use the machine as a bot-net. That's likely not going to have much of an effect on your local machine (besides increasing load), but it *is* a security concern. signature.asc Description: This is a digitally signed message part -- 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: Allow internet/network access based on binary -- ask user for permission if a binary wants to connect to the internet
You can do this with SELinux and confined users somewhat.
YOU basically could setup a user as xguest with no network access and
then write
policy to transition to certain domains that can use the internet. No
ability to prompt the user
though.
This will get you most of the way you want to go, but somethings can be
tricky.
Also lots of apps contact the network just by calling getpw* calls, if
you have certain settings in nsswitch.
On 12/09/2014 06:16 AM, Bastien Nocera wrote:
- Original Message -
I only want certain binaries to be allowed network access.
For example, I want to allow the below binaries access to the internet:
/usr/lib64/firefox/firefox
/usr/lib/virtualbox/VirtualBox
/bin/yum (it seems to be done via python like /usr/bin/python /bin/yum
update -- so here obviously python is allowed network access only for
yum ('the binary'). This rule should not give python network access
for any other binaries/.py scripts etc.)
I want no other binary to be able to access the network.
It's not implementable, because you have no way to know that the
binary trying to access the network is what it says it is.
For now, at least. We'll certainly get something like that when
application sandboxing is implemented and deployed.
--
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: Workstation Product defaults to wide-open firewall
- Original Message - From: Robert Marcano rob...@marcanoonline.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, December 9, 2014 8:57:51 AM Subject: Re: Workstation Product defaults to wide-open firewall On 12/09/2014 08:53 AM, Reindl Harald wrote: Am 09.12.2014 um 14:16 schrieb Bastien Nocera: On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? We can — we just need someone to design and write it. A design for something that we don't want to implement. and that is the point - you do not want and care because you seem to think users are too stupid to make their own decisions - you know what Linus said to that in direction of GNOME? This was one of the options when implementing the feature, one that we didn't pursue. We chose instead to use user intent as a way to do this. If you start sharing something on a network, then we consider it safe to share. the problem is that you don't know *who* or *what* opened the port Exactly, I think some people think we already reached the utopic world, when everyone install FLOSS applications from the repositories, and no one uses closed source applications, or worse where all sharing is done using GNOME control panel, and there isn't applications that doesn't take into account the GNOME way of doing things. What I see frequently are applications that are installed from outside the Fedora repositories, that can be forced to behave like Fedora packaging rules, with secure defaults before sharing, being installed and the user that don't know much about firewall settings but understand that the firewall is active, then think: I feel secure because I know the firewall is blocking external requests. Speaking from personal experience my thoughts was never 'I feel so safe', instead I just felt annoyed that for the gazilliont time things didn't work due to the firewall blocking the application or service or I was trying to run. And after trying to Google and only finding Ubuntu specific commands that never seemed to work or commands which was only relevant to Fedora 12, I tended to disable the firewall while asking myself while after all these years things still sucked as much. Christian and then in that utopic world things fail, for example, Fedora packaging rules prefer that packages are installed with sensitive defaults, I reported a bug about all cron email output being sent by default and it was discarded as a security bug (pulled by an update) https://bugzilla.redhat.com/show_bug.cgi?id=1157727 https://bugzilla.redhat.com/show_bug.cgi?id=1158493 https://lists.fedoraproject.org/pipermail/devel/2014-October/203781.html This is no open port, but shows that packages can have bugs and something that is closed by default today, can in the future be pulled as an update and start sharing things. Those are bugs, true, but the idea of opening the firewall entirely defeats the measure of defense already in place. To me it sounds like disabling SELinux on workstation because people find it difficult and decide to disable it instead. The problem that is being tried to solve is that people choose to disable the firewall, Why not add a simple option to the GNOME sharing tools to change the firewall zone to this one where ports 1024 are open when the user decide to share something. with the possibility to selecting no for those people that only want to open the only the needed ports? Note: I hope to not be called a troll here (joke, someone will understand) If you connect to a public unencrypted Wi-Fi, you won't have the option to. If you connect to an encrypted Wi-Fi where sharing your holiday photos isn't acceptable then it won't, because you didn't ask it to in the first place besides suspend / move machine a sane firewall design (sadly Windows has that in the meantime) is that if i open a port in my homenetwork, supsend the machine and wake it up in a foreign network ports are closed until i decide to open them there too, but Fedora goes the easy way who cares how and why as long things appear to work *who* told you that people don't share things *unintentional* by a wrong click which is *not* a problem until you decide to open ports -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
- Original Message - From: Brian Wheeler bdwhe...@indiana.edu To: devel@lists.fedoraproject.org Sent: Tuesday, December 9, 2014 9:18:47 AM Subject: Re: Workstation Product defaults to wide-open firewall On 12/09/2014 08:50 AM, Richard Hughes wrote: On 9 December 2014 at 13:39, Michael Catanzaro mcatanz...@gnome.org wrote: So your challenge is to find an alternative default that supports it. I'd go even further. I don't think the people writing the vast number of lengthy posts on this thread actually want to *use* workstation, with the possible exception of Bastien who's having to defend something he shouldn't have to. Reindl probably should just use the server spin, or be prepared to actually configure his box to do what he wants to be 100% paranoid and unusable for anything less than a technical user. If you don't like what workstation has decided to do, use another target, or a different distro entirely (like CentOS). If you want to change how workstation is designed, join the working group and please actually talk to people there. I think it's misguided to think that hurling insults here is going to achieve change. I think a lot of people also need to remember that workstation isn't built for them, and that's okay. If you know how to configure iptables then that's fine, but I'm happy to admit I don't, and normally just switch off the firewall entirely so I can get stuff done. F21 will be more secure for me, not less. Ok, so what product/spin am I supposed to use? I'm a RHEL sysadmin but I use Fedora on my desktop laptop. I expect the firewall to be on so when I evaluate a new piece of software or do a bit of network development I don't inadvertently increase my exposure. I also expect things to work with the minimum amount of fuss. So it looks like my choices boil down to: * Use the workstation project and spend a bunch of time locking it down to what would be reasonable default for the networks I use -- and hope I don't miss anything. Well I think it is hard for anyone to guess what would be reasonable defaults for you specifically, any default is by its nature just targeting an generic person, which might or might not be a lot like you. But if you are aware and understand the finer details here then it isn't that big a job to change it, you should be able to go into the network manager, choose your connection, choose 'identity' (should probably be moved to be under security?) and change the zone for your network to whatever suits you better. Christian * Use the server product and manually configure all of the workstation stuff so I get a usable system Neither of those choices seem reasonable to me, especially compared to the status quo: a fully configured workstation where I open new ports as I increase functionality. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
Am 09.12.2014 um 15:57 schrieb Christian Schaller: Well I think it is hard for anyone to guess what would be reasonable defaults for you specifically, any default is by its nature just targeting an generic person, which might or might not be a lot like you. But if you are aware and understand the finer details here then it isn't that big a job to change it, you should be able to go into the network manager, choose your connection, choose 'identity' (should probably be moved to be under security?) and change the zone for your network to whatever suits you better. and why can't you do the same if you want it open instead start wide-open and expect from people to secure their system how long do you think does it take until someone is so audacious and installs mysql and apache with the intention just to develop some webscripts on his workstation *beause* he want only play around with it not imaging that his mysqld is open to the world and not just localhost? the same applies for *any* other service in /etc/services with a port number above 1024 - ship unsecure defaults and expect users to secure their machines is pervert - that won't happen, sooner or later damage will happen and nobody feels responsible 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
Announcing Fedora 21!
Fedora 21 Release Announcement == http://fedoramagazine.org/announcing-fedora-21/ The Fedora Project is pleased to announce the release of Fedora 21, ready to run on your desktops, servers, and in the cloud. Fedora 21 is a game-changer for the Fedora Project, and we think you're going to be very pleased with the results. Fedora.next and Fedora 21 Flavors = As part of the Fedora.next initiative, Fedora 21 comes in three flavors: Cloud, Server, and Workstation -- whether you're using Linux on your laptop, using Linux on your servers, or spinning up containers or images in the cloud, we have what you need to be successful. Fedora 21 Base -- Each of the flavors builds on the base set of packages for Fedora. For instance, each flavor uses the same packages for the kernel, RPM, Yum, systemd, Anaconda, and so forth. The Base Working Group develops the standard platform for all Fedora deliverables, which includes the installer, compose tools, and basic platform for the other flavors. The Base set of packages *is not* intended for use on its own, but is kept as a small, stable platform for other initiatives to build on. Highlights in the Fedora 21 Release === Fedora 21 Cloud --- The Fedora Cloud Working Group and Special Interest Group (SIG) has been busy leading up to Fedora 21. Cloud is now a top-level deliverable for Fedora 21, and includes images for use in private cloud environments like OpenStack, as well as AMIs for use on Amazon, and a new Atomic image streamlined for running Docker containers. * Modular Kernel Packaging for Cloud Space is precious, and there's little reason to include drivers for hardware that doesn't exist in the cloud. As part of the work for this release, the cloud SIG and kernel team split the kernel into two packages. One package contains the minimum modules for running in a virtualized environment, the other contains the larger set of modules for a more general installation. With other size reduction work, the F21 cloud image is about 25% smaller than F20, making for faster deployment and more room to whatever *you* need. * Fedora Atomic Host In early April, Red Hat announced Project Atomic, an effort to provide the tools and patterns for a streamlined operating system to run containers. The Fedora 21 release is the first to offer an Atomic host for Fedora, which includes a minimal set of packages and an image composed with rpm-ostree. While using the same RPMs as other Fedora offerings, the Atomic host lets you roll back updates (if necessary) as one atomic unit -- making update management much easier. Our Atomic image includes Kubernetes and Cockpit for container management, and will receive updates through the Fedora 21 release cycle as rpm-ostree updates. Fedora 21 Server The Fedora Server flavor is a common base platform that is meant to run featured application stacks, which are produced, tested, and distributed by the Server Working Group. Want to use Fedora as a Web server, file server, database server, or platform for an Infrastructure-as-a-Service? Fedora 21 Server is for you. * Fedora Server Management Features The Fedora Server flavor introduces new Server management features aimed at making it easier to install discrete infrastructure services. The Fedora Server introduces three new technologies to handle this task, rolekit, Cockpit, and OpenLMI. Rolekit is a Role deployment and management toolkit that provides a consistent interface to administrators to install and configure all the packages needed to implement a specific server role. Rolekit is at an early stage of development in Fedora 21. Cockpit is a user interface for configuring and monitoring your server or servers. It is accessible remotely via a web browser. OpenLMI is a remote management system built atop DMTF-CIM. Use OpenLMI for scripting management functions across many machines and for querying for capabilities and monitoring for system events. * Domain Controller Server Role As part of the server role offerings available for Fedora 21, the Server flavor ships with a role deployment mechanism. One of the roles offered in 21 is the Domain Controller Service. The Domain Controller Service packages freeIPA's integrated identity and authentication solution for Linux/UNIX networked environments. A FreeIPA server provides centralized authentication, authorization, and account information by storing data about user, groups, hosts, and other objects necessary to manage the security aspects of a network of computers. Fedora 21 Workstation - The Fedora Workstation is a new take on desktop development from the Fedora community. Our goal is to pick the best components, and integrate and polish them. This work results in a more polished and targeted
Re: Workstation Product defaults to wide-open firewall
On 12/09/2014 03:57 PM, Christian Schaller wrote: - Original Message - From: Brian Wheeler bdwhe...@indiana.edu To: devel@lists.fedoraproject.org Sent: Tuesday, December 9, 2014 9:18:47 AM Subject: Re: Workstation Product defaults to wide-open firewall On 12/09/2014 08:50 AM, Richard Hughes wrote: On 9 December 2014 at 13:39, Michael Catanzaro mcatanz...@gnome.org wrote: So your challenge is to find an alternative default that supports it. I'd go even further. I don't think the people writing the vast number of lengthy posts on this thread actually want to *use* workstation, with the possible exception of Bastien who's having to defend something he shouldn't have to. Reindl probably should just use the server spin, or be prepared to actually configure his box to do what he wants to be 100% paranoid and unusable for anything less than a technical user. If you don't like what workstation has decided to do, use another target, or a different distro entirely (like CentOS). If you want to change how workstation is designed, join the working group and please actually talk to people there. I think it's misguided to think that hurling insults here is going to achieve change. I think a lot of people also need to remember that workstation isn't built for them, and that's okay. If you know how to configure iptables then that's fine, but I'm happy to admit I don't, and normally just switch off the firewall entirely so I can get stuff done. F21 will be more secure for me, not less. Ok, so what product/spin am I supposed to use? I'm a RHEL sysadmin but I use Fedora on my desktop laptop. I expect the firewall to be on so when I evaluate a new piece of software or do a bit of network development I don't inadvertently increase my exposure. I also expect things to work with the minimum amount of fuss. So it looks like my choices boil down to: * Use the workstation project and spend a bunch of time locking it down to what would be reasonable default for the networks I use -- and hope I don't miss anything. Well I think it is hard for anyone to guess what would be reasonable defaults for you specifically, any default is by its nature just targeting an generic person, which might or might not be a lot like you. But if you are aware and understand the finer details here then it isn't that big a job to change it, you should be able to go into the network manager, choose your connection, choose 'identity' (should probably be moved to be under security?) and change the zone for your network to whatever suits you better. Please change the default zone, otherwise any new connection will get assigned to the weak zone again in the first place. firewall-cmd --set-default-zone=public This will change the default to public. All connections that are not explicitly bound to another zone will be automatically assigned to the default zone. Thomas Christian * Use the server product and manually configure all of the workstation stuff so I get a usable system Neither of those choices seem reasonable to me, especially compared to the status quo: a fully configured workstation where I open new ports as I increase functionality. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
- Original Message - On Mon, 8 Dec 2014 05:45:56 -0500 (EST) Bastien Nocera bnoc...@redhat.com wrote: No, because that'd be awful UI. Is it really so awful to ask a user: Do you want to expose Eclipse to the network ? (of course worded in a better way than my poor English skills can do). Probably not, but it's not implementable in the current state of things. I think users can understand such a question, and you do not need to mention ports or TCP or firewalls even. It's just a question about whether you really want to expose a specific service to a network, you do it once and record it somewhere where a user can go back and tweak the setting if they change their mind. -- 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: Workstation Product defaults to wide-open firewall
- Original Message - On 12/09/2014 08:50 AM, Richard Hughes wrote: On 9 December 2014 at 13:39, Michael Catanzaro mcatanz...@gnome.org wrote: So your challenge is to find an alternative default that supports it. I'd go even further. I don't think the people writing the vast number of lengthy posts on this thread actually want to *use* workstation, with the possible exception of Bastien who's having to defend something he shouldn't have to. Reindl probably should just use the server spin, or be prepared to actually configure his box to do what he wants to be 100% paranoid and unusable for anything less than a technical user. If you don't like what workstation has decided to do, use another target, or a different distro entirely (like CentOS). If you want to change how workstation is designed, join the working group and please actually talk to people there. I think it's misguided to think that hurling insults here is going to achieve change. I think a lot of people also need to remember that workstation isn't built for them, and that's okay. If you know how to configure iptables then that's fine, but I'm happy to admit I don't, and normally just switch off the firewall entirely so I can get stuff done. F21 will be more secure for me, not less. Ok, so what product/spin am I supposed to use? I'm a RHEL sysadmin but I use Fedora on my desktop laptop. I expect the firewall to be on so when I evaluate a new piece of software or do a bit of network development I don't inadvertently increase my exposure. I also expect things to work with the minimum amount of fuss. So it looks like my choices boil down to: * Use the workstation project and spend a bunch of time locking it down to what would be reasonable default for the networks I use -- and hope I don't miss anything. The defaults for the various products are packaged by zones. You just need to change the firewalld zone to get whatever is the default on the server side. Or better, use VMs to deploy test instances which would have the same set of packages and configuration as a Fedora Server version. * Use the server product and manually configure all of the workstation stuff so I get a usable system Neither of those choices seem reasonable to me, especially compared to the status quo: a fully configured workstation where I open new ports as I increase functionality. Using a VM is probably a better idea than deploying test servers on a desktop machine. -- 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: Workstation Product defaults to wide-open firewall
- Original Message - Hi, I also thought that the whole points of having Zones etc, was so that we could pick a different zone per network connection, /me too. so if I'm in the office or at home I can say use this zone, if I'm at a coffee shop I can pick a different one etc. Or was this consider too much UI for the normal user? Surely OSX has something to copy from, since they seem to define what a normal user expects. OSX has a firewall integration that I would rank as awful. It's not any better than what we had in Fedora 20 (blocking firewall and a tool to open up ports). Have a look at Windows then. Each time you hook a windows machine to a new network it asks what network this is. Used to be public, home, work. Recently they simplified that and kicked the home / work separation, so it's only public / non-public now. With some explanation along the lines of use public for hotspots, use home for your private network where you want share stuff. Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? Side Note: For the latter we need to cleanup the zones though. There are *way* to many to choose from, and the names suck big time. WTF is a Fedora$product zone? And wasn't that discussed before on this list? Why do we *still* have this mess? This isn't a side note, IMO. It was one of the major reasons why we chose not to expose users to the concept of zones. In addition to the names being obscure in firewalld (there's a bug filed about that), they also are obscure in Windows. What configuration difference is there between home and work, and how do you explain them without going deeper into technical details? Are there cases where I want to share things in a work environment and not a home environment? IMO there is simply no way around asking the user. Instead of asking the user, we're getting the user to tell us they want to share things. This avoids unnecessary nagging. Make sharing stuff easy (so you can watch your dnla-exported photo/video collection at your smart tv) is a reasonable request. But enabling that by allowing everybody fetch your private photo collection via dnla while you are surfing @ starbucks is a non-starter. This isn't what was implemented. DLNA share will be turned off by default on new networks. In fact, we won't allow any unencrypted services to run when on unencrypted Wi-Fi. cheers, Gerd PS: Seems windows can even identify different wired networks. I've switched my router recently, and windows re-asked what network I'm on. Probably they remember the mac address of the default gateway or something like that. This will be implemented as soon as NetworkManager makes it easier for us to detect different wired connections. For now, all wired connections are considered to be the same one, which could be a problem. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On Di, 2014-12-09 at 08:16 -0500, Bastien Nocera wrote: - Original Message - On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? We can — we just need someone to design and write it. A design for something that we don't want to implement. This was one of the options when implementing the feature, one that we didn't pursue. We chose instead to use user intent as a way to do this. If you start sharing something on a network, then we consider it safe to share. If you connect to a public unencrypted Wi-Fi, you won't have the option to. If you connect to an encrypted Wi-Fi where sharing your holiday photos isn't acceptable then it won't, because you didn't ask it to in the first place. That assumes all applications behave that way. Which simply isn't true, there is a world outside gnome. You apparently choose to ignore that, which is a bad idea IMO. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Allow internet/network access based on binary -- ask user for permission if a binary wants to connect to the internet
- Original Message - You can do this with SELinux and confined users somewhat. YOU basically could setup a user as xguest with no network access and then write policy to transition to certain domains that can use the internet. No ability to prompt the user though. This will get you most of the way you want to go, but somethings can be tricky. Yeah, one user per application is certainly not something we'd want to implement ;) Also lots of apps contact the network just by calling getpw* calls, if you have certain settings in nsswitch. SELinux is probably going to have a lot of use in identifying/vouching for applications in the sandboxed world, but we're not there just yet. -- 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: Workstation Product defaults to wide-open firewall
On Tue, 9 Dec 2014 10:09:07 -0500 (EST) Bastien Nocera bnoc...@redhat.com wrote: - Original Message - On Mon, 8 Dec 2014 05:45:56 -0500 (EST) Bastien Nocera bnoc...@redhat.com wrote: No, because that'd be awful UI. Is it really so awful to ask a user: Do you want to expose Eclipse to the network ? (of course worded in a better way than my poor English skills can do). Probably not, but it's not implementable in the current state of things. Understood. Do we have a way to get there ? (trying to be constructive here) Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On Mon, 8 Dec 2014 05:45:56 -0500 (EST) Bastien Nocera bnoc...@redhat.com wrote: No, because that'd be awful UI. Is it really so awful to ask a user: Do you want to expose Eclipse to the network ? (of course worded in a better way than my poor English skills can do). I think users can understand such a question, and you do not need to mention ports or TCP or firewalls even. It's just a question about whether you really want to expose a specific service to a network, you do it once and record it somewhere where a user can go back and tweak the setting if they change their mind. Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
- Original Message - From: Gerd Hoffmann kra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, December 9, 2014 10:22:01 AM Subject: Re: Workstation Product defaults to wide-open firewall On Di, 2014-12-09 at 08:16 -0500, Bastien Nocera wrote: - Original Message - On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? We can — we just need someone to design and write it. A design for something that we don't want to implement. This was one of the options when implementing the feature, one that we didn't pursue. We chose instead to use user intent as a way to do this. If you start sharing something on a network, then we consider it safe to share. If you connect to a public unencrypted Wi-Fi, you won't have the option to. If you connect to an encrypted Wi-Fi where sharing your holiday photos isn't acceptable then it won't, because you didn't ask it to in the first place. That assumes all applications behave that way. Which simply isn't true, there is a world outside gnome. You apparently choose to ignore that, which is a bad idea IMO. Well we are not shipping by default anything which doesn't conform to this, and if you go out of your way to install something I don't think it is far fetched to assume you want that thing to work. Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
- Original Message - On Tue, 9 Dec 2014 10:09:07 -0500 (EST) Bastien Nocera bnoc...@redhat.com wrote: - Original Message - On Mon, 8 Dec 2014 05:45:56 -0500 (EST) Bastien Nocera bnoc...@redhat.com wrote: No, because that'd be awful UI. Is it really so awful to ask a user: Do you want to expose Eclipse to the network ? (of course worded in a better way than my poor English skills can do). Probably not, but it's not implementable in the current state of things. Understood. Do we have a way to get there ? (trying to be constructive here) 1. Land kdbus 2. Implement sandboxing support, including a way for system services to securely identify applications talking to them, and/or block particular capabilities (such as network access, filesystem access, etc.) 3. Profit! -- 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: Workstation Product defaults to wide-open firewall
On 12/09/2014 11:01 AM, Christian Schaller wrote: - Original Message - From: Gerd Hoffmann kra...@redhat.com To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, December 9, 2014 10:22:01 AM Subject: Re: Workstation Product defaults to wide-open firewall On Di, 2014-12-09 at 08:16 -0500, Bastien Nocera wrote: - Original Message - On Tue, Dec 09, 2014 at 12:54:59PM +0100, Gerd Hoffmann wrote: Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? We can — we just need someone to design and write it. A design for something that we don't want to implement. This was one of the options when implementing the feature, one that we didn't pursue. We chose instead to use user intent as a way to do this. If you start sharing something on a network, then we consider it safe to share. If you connect to a public unencrypted Wi-Fi, you won't have the option to. If you connect to an encrypted Wi-Fi where sharing your holiday photos isn't acceptable then it won't, because you didn't ask it to in the first place. That assumes all applications behave that way. Which simply isn't true, there is a world outside gnome. You apparently choose to ignore that, which is a bad idea IMO. Well we are not shipping by default anything which doesn't conform to this, and if you go out of your way to install something I don't think it is far fetched to assume you want that thing to work. I want that thing to work for me, not for everyone on the network unless I allow it (open the firewall). External applications, specially closed source ones, with bad defaults exists and that will never stop Christian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
- Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, December 9, 2014 10:04:46 AM Subject: Re: Workstation Product defaults to wide-open firewall Am 09.12.2014 um 15:57 schrieb Christian Schaller: Well I think it is hard for anyone to guess what would be reasonable defaults for you specifically, any default is by its nature just targeting an generic person, which might or might not be a lot like you. But if you are aware and understand the finer details here then it isn't that big a job to change it, you should be able to go into the network manager, choose your connection, choose 'identity' (should probably be moved to be under security?) and change the zone for your network to whatever suits you better. and why can't you do the same if you want it open instead start wide-open and expect from people to secure their system I think the part of the sentence you probably missed was if you are aware and understand the finer details here, because for anyone who doesn't understand the finer details here you are suggesting we default the system to 'broken'. how long do you think does it take until someone is so audacious and installs mysql and apache with the intention just to develop some webscripts on his workstation *beause* he want only play around with it not imaging that his mysqld is open to the world and not just localhost? the same applies for *any* other service in /etc/services with a port number above 1024 - ship unsecure defaults and expect users to secure their machines is pervert - that won't happen, sooner or later damage will happen and nobody feels responsible -- 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: Workstation Product defaults to wide-open firewall
Am 09.12.2014 um 16:40 schrieb Christian Schaller: - Original Message - From: Reindl Harald h.rei...@thelounge.net To: devel@lists.fedoraproject.org Sent: Tuesday, December 9, 2014 10:04:46 AM Subject: Re: Workstation Product defaults to wide-open firewall Am 09.12.2014 um 15:57 schrieb Christian Schaller: Well I think it is hard for anyone to guess what would be reasonable defaults for you specifically, any default is by its nature just targeting an generic person, which might or might not be a lot like you. But if you are aware and understand the finer details here then it isn't that big a job to change it, you should be able to go into the network manager, choose your connection, choose 'identity' (should probably be moved to be under security?) and change the zone for your network to whatever suits you better. and why can't you do the same if you want it open instead start wide-open and expect from people to secure their system I think the part of the sentence you probably missed was if you are aware and understand the finer details here, because for anyone who doesn't understand the finer details here you are suggesting we default the system to 'broken' than it's an education / documentation problem and nothing else finer details is just polemic i don't want to live in a world where even free operating systems are going down the road declare anything as finer details and sacrifice security because someone needs to think 2 minutes frankly that 2 minutes thinking may lead to uhm maybe not the best idea - *what in the world* let you come to the conclusion that ignore the lessons Microsoft learned in times where everybody pointed at Windows with wide open defaults and now going back to the state from where they came is a good design decision? to we *really* want to go the road down to a point where people say a Windows default setup is more safe then modern Linux systems? 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
[Bug 1163236] perl-Git-CPAN-Patch-2.0.3 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1163236 Petr Šabata psab...@redhat.com changed: What|Removed |Added Depends On||1172210 Referenced Bugs: https://bugzilla.redhat.com/show_bug.cgi?id=1172210 [Bug 1172210] Review Request: perl-Git-Repository-Plugin-AUTOLOAD - Git subcommands as Git::Repository methods -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=UiVRvqSHkWa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Workstation Product defaults to wide-open firewall
On 12/09/2014 10:11 AM, Bastien Nocera wrote: The defaults for the various products are "packaged" by zones. You just need to change the firewalld zone to get whatever is the default on the server side. Ok, so it's another item on my list of "things to fix that fedora didn't get right" after I do an install. The release notes are misleading, at best. All of the arguments I've heard used to justify this change have been boiled down to "end users don't understand networking" -- which means that calling this feature "developer oriented" in the release notes is wrong. There should be a far larger warning that any software that opens a non-privileged port is accessible to the world. If I didn't do development (and if I hadn't read this thread) then I would probably have skipped that section and left my machine open to the world. Or better, use VMs to deploy test instances which would have the same set of packages and configuration as a Fedora Server version. Proposing VMs is just moving the goalposts, especially if I have client-oriented software that wants to open ports. And for developer things it means maintaining/securing two installations instead of one. -- 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: Announcing Fedora 21!
thanks! seeding the torrent images from now on via qbittorrent-nox http://torrent.fedoraproject.org/torrents/Fedora-Server-DVD-x86_64-21.torrent http://torrent.fedoraproject.org/torrents/Fedora-Server-DVD-i386-21.torrent http://torrent.fedoraproject.org/torrents/Fedora-Live-Workstation-x86_64-21.torrent http://torrent.fedoraproject.org/torrents/Fedora-Live-Workstation-i686-21.torrent http://torrent.fedoraproject.org/torrents/Fedora-Live-KDE-x86_64-21.torrent http://torrent.fedoraproject.org/torrents/Fedora-Live-KDE-i686-21.torrent Am 09.12.2014 um 16:04 schrieb Matthew Miller: Fedora 21 Release Announcement == http://fedoramagazine.org/announcing-fedora-21/ The Fedora Project is pleased to announce the release of Fedora 21, ready to run on your desktops, servers, and in the cloud. Fedora 21 is a game-changer for the Fedora Project, and we think you're going to be very pleased with the results. Fedora.next and Fedora 21 Flavors = As part of the Fedora.next initiative, Fedora 21 comes in three flavors: Cloud, Server, and Workstation -- whether you're using Linux on your laptop, using Linux on your servers, or spinning up containers or images in the cloud, we have what you need to be successful. Fedora 21 Base -- Each of the flavors builds on the base set of packages for Fedora. For instance, each flavor uses the same packages for the kernel, RPM, Yum, systemd, Anaconda, and so forth. The Base Working Group develops the standard platform for all Fedora deliverables, which includes the installer, compose tools, and basic platform for the other flavors. The Base set of packages *is not* intended for use on its own, but is kept as a small, stable platform for other initiatives to build on. Highlights in the Fedora 21 Release === Fedora 21 Cloud --- The Fedora Cloud Working Group and Special Interest Group (SIG) has been busy leading up to Fedora 21. Cloud is now a top-level deliverable for Fedora 21, and includes images for use in private cloud environments like OpenStack, as well as AMIs for use on Amazon, and a new Atomic image streamlined for running Docker containers. * Modular Kernel Packaging for Cloud Space is precious, and there's little reason to include drivers for hardware that doesn't exist in the cloud. As part of the work for this release, the cloud SIG and kernel team split the kernel into two packages. One package contains the minimum modules for running in a virtualized environment, the other contains the larger set of modules for a more general installation. With other size reduction work, the F21 cloud image is about 25% smaller than F20, making for faster deployment and more room to whatever *you* need. * Fedora Atomic Host In early April, Red Hat announced Project Atomic, an effort to provide the tools and patterns for a streamlined operating system to run containers. The Fedora 21 release is the first to offer an Atomic host for Fedora, which includes a minimal set of packages and an image composed with rpm-ostree. While using the same RPMs as other Fedora offerings, the Atomic host lets you roll back updates (if necessary) as one atomic unit -- making update management much easier. Our Atomic image includes Kubernetes and Cockpit for container management, and will receive updates through the Fedora 21 release cycle as rpm-ostree updates. Fedora 21 Server The Fedora Server flavor is a common base platform that is meant to run featured application stacks, which are produced, tested, and distributed by the Server Working Group. Want to use Fedora as a Web server, file server, database server, or platform for an Infrastructure-as-a-Service? Fedora 21 Server is for you. * Fedora Server Management Features The Fedora Server flavor introduces new Server management features aimed at making it easier to install discrete infrastructure services. The Fedora Server introduces three new technologies to handle this task, rolekit, Cockpit, and OpenLMI. Rolekit is a Role deployment and management toolkit that provides a consistent interface to administrators to install and configure all the packages needed to implement a specific server role. Rolekit is at an early stage of development in Fedora 21. Cockpit is a user interface for configuring and monitoring your server or servers. It is accessible remotely via a web browser. OpenLMI is a remote management system built atop DMTF-CIM. Use OpenLMI for scripting management functions across many machines and for querying for capabilities and monitoring for system events. * Domain Controller Server Role As part of the server role offerings available for Fedora 21, the Server flavor ships with a role deployment mechanism. One of the roles offered in 21 is the Domain Controller Service.
Re: Workstation Product defaults to wide-open firewall
Hi, Side Note: For the latter we need to cleanup the zones though. There are *way* to many to choose from, and the names suck big time. WTF is a Fedora$product zone? And wasn't that discussed before on this list? Why do we *still* have this mess? This isn't a side note, IMO. It was one of the major reasons why we chose not to expose users to the concept of zones. IMO it would have been better to fix the zones instead. The concept is good, we just have too many with of them, with bad names. We basically need one for public networks (Hotspots etc) and one for Home/Work, with good names and sensible defaults. Maybe also allow all and block all (including outgoing traffic) zones, but thats it. The internal, external, dmz, ... zones sound like they are intended for machines running as router. They should either be moved to a subpackage (so they are not installed by default), or dropped altogether. Or maybe tagged as expert zones, so they are hidden by default in the UI. In addition to the names being obscure in firewalld (there's a bug filed about that), they also are obscure in Windows. What configuration difference is there between home and work, and how do you explain them without going deeper into technical details? Microsoft figured this too, so as I've already mentioned this home/work is gone now (win8 fully updated). IMO there is simply no way around asking the user. Instead of asking the user, we're getting the user to tell us they want to share things. This avoids unnecessary nagging. Problem is this doesn't work for apps outside the gnome universe. For example I can ask libvirt to make the qemu vnc server listen on any interface, if I want access the guest screen from another machine. With firewall zones I can easily get the behavior I want: guest screen is reachable in my home network, but not in the coffee shop. Make sharing stuff easy (so you can watch your dnla-exported photo/video collection at your smart tv) is a reasonable request. But enabling that by allowing everybody fetch your private photo collection via dnla while you are surfing @ starbucks is a non-starter. This isn't what was implemented. DLNA share will be turned off by default on new networks. In fact, we won't allow any unencrypted services to run when on unencrypted Wi-Fi. The gnome dnla server might do this. There are other dnla servers, and other apps opening network ports, which don't follow this policy. cheers, Gerd -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 12/08/2014 06:41 PM, Reindl Harald wrote: the security community is usually very clear: * forbid as much as you can by default * allow only what *really* is needed to get the work done ...and this is the tricky part---you want tightly defined functionality, and other people want to install a photo-sharing that just works with their off-the-shelf smart TV. In principle, both could be accomplished with a combination of well-written, good-looking pop-up dialogs and a smart, dynamic firewall, but the required software doesn't exit yet. I think that we should start with the low hanging fruit and simplify the firewall zones to two : a public, restricted one and a home/private with more ports open; selected by user for each new interface. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora ARM AArch64 Status Meeting Minutes 2014-12-09
== #fedora-meeting-2: Fedora ARM AArch64 Status Meeting == Meeting started by pwhalen at 15:02:22 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting-2/2014-12-09/fedora-meeting-2.2014-12-09-15.02.log.html . Meeting summary --- * roll call (pwhalen, 15:02:56) * 1) Fedora 21 Status (armhfp) = (pwhalen, 15:04:43) * Fedora 21 Installation Documentation (pwhalen, 15:04:53) * LINK: https://fedoraproject.org/wiki/Architectures/ARM/F21/Installation (pwhalen, 15:05:01) * ACTION: pwhalen to add appropriate link for Workstation image (pwhalen, 15:07:34) * Fedora 21 released today! (pwhalen, 15:07:56) * common bugs for F-21 are listed here https://fedoraproject.org/wiki/Common_F21_bugs (pbrobinson, 15:11:15) * Testing of F22 has begun (pwhalen, 15:12:36) * LINK: https://fedoraproject.org/wiki/Test_Results:Fedora_22_20141208_Summary#ARM_disk_images (pwhalen, 15:12:43) * 2) Fedora 21 (aarch64) (pwhalen, 15:16:41) * 2a) == Open Bugs == (pwhalen, 15:16:41) * New Lorax build needing karma (pwhalen, 15:18:31) * LINK: https://admin.fedoraproject.org/updates/FEDORA-2014-16415/lorax-21.32-1.fc21 (pwhalen, 15:18:32) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1170289 (shim spec file hardcodes DEFAULT_LOADER=grubx64.efi even for aarch64)? (hrw, 15:19:48) * ACTION: ALL: Test RC6, if working leave karma - https://admin.fedoraproject.org/updates/FEDORA-2014-16415/lorax-21.32-1.fc21 (pwhalen, 15:20:26) * AGREED: F21 for aarch64 will use shim-0.8-2.fc21 and shim-signed-0.8-5 (bconoboy, 15:41:44) * Installer unable to add bootloader EFI entry on AArch64 (pwhalen, 15:42:00) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1151571 (pwhalen, 15:42:00) * the inclusion of shim-0.8-2.fc21 and shim-signed-0.8-5 is an exception of different NVR from primary for F-21 only and will be fixed moving forward (pbrobinson, 15:42:49) * Bundling exception for coffee-script (pwhalen, 15:46:56) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1166489 (pwhalen, 15:46:56) * No KVM virtualization on APM Mustang and other boards (3.17.4/f21 and 3.18-rc/f22) (pwhalen, 15:48:09) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1165290 (pwhalen, 15:48:09) * This is a firmware bug, a one line workaround has been introduced into the aarch64 kernel. To be tested in next RC (bconoboy, 15:49:43) * aarch64: anaconda in VM dies with SystemError: Could not determine system architecture. because blivet assumes aarch64 always has EFI (pwhalen, 15:50:45) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=1128341 (pwhalen, 15:50:45) * AGREED: Defer to next week (bconoboy, 15:56:47) * 2b) == F21 Aarch64 Deliverables Planning == (pwhalen, 15:57:27) * pbrobinson to compose RC6 for testing (pwhalen, 15:57:47) * 3) OPen Floor (pwhalen, 15:58:34) Meeting ended at 16:00:59 UTC. Action Items * pwhalen to add appropriate link for Workstation image * ALL: Test RC6, if working leave karma - https://admin.fedoraproject.org/updates/FEDORA-2014-16415/lorax-21.32-1.fc21 Action Items, by person --- * pwhalen * pwhalen to add appropriate link for Workstation image * **UNASSIGNED** * ALL: Test RC6, if working leave karma - https://admin.fedoraproject.org/updates/FEDORA-2014-16415/lorax-21.32-1.fc21 People Present (lines said) --- * pwhalen (76) * pbrobinson (48) * bconoboy (42) * pjones (29) * hrw (15) * zodbot (12) * yselkowitz (8) * Corey84- (8) * masta (5) * jsmith (1) * dmarlin (0) * jonmasters (0) * dgilmore (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Request to take over orphaned python-mutagen
That's a good thing. Looking forward to seeing the new version made available which now supports Python3. Thanks Michele! On Tue, Dec 9, 2014 at 1:21 AM, Michele Baldessari mich...@acksyn.org wrote: Hi all, as per [1], I'd like to take over the orphaned python-mutagen package. Let me know if there are any objections. Cheers, Michele [1] https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Claiming_Ownership_of_an_Orphaned_Package_Procedure -- Michele Baldessarimich...@acksyn.org C2A5 9DA3 9961 4FFB E01B D0BC DDD4 DCCB 7515 5C6D -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On 9 December 2014 at 14:18, Brian Wheeler bdwhe...@indiana.edu wrote: I also expect things to work with the minimum amount of fuss. So do I! I'm a developer, which spin do I use so that the firewall doesn't get in my way? We can't develop a *product* based around what you specifically want, not me, nor anyone else on this list. So it looks like my choices boil down to: * Use the workstation project and spend a bunch of time locking it down to what would be reasonable default for the networks I use -- and hope I don't miss anything. Sure, you can do that, you seem more technically proficient with firewalls than me. If you want to trust the system, you've got to be able to understand it. * Use the server product and manually configure all of the workstation stuff so I get a usable system You sound like you can do that too. Neither of those choices seem reasonable to me, especially compared to the status quo: a fully configured workstation where I open new ports as I increase functionality. I don't think it makes much sense for people to stamp their feet saying BUT I LIKED THE OLD WAY OF DOING THINGS when the people leading the workstation product have identified that the old way of doing things just doesn't work for the majority of people. You're probably not in that majority, but that doesn't mean the change is in someway intrinsically flawed. Richard -- 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: Workstation Product defaults to wide-open firewall
On Mon, Dec 8, 2014 at 11:59 PM, William B will...@firstyear.id.au wrote: The true crux of this issue is the over complexity that firewalld has brought to fedora, and the fact that a quality UI for managing it does not exist yet. OSX solves this issue by having an on or off button, and a list of applications that are allowed access. When the application first requests access, a prompt is given to add the application to the allow list. Why are we so against such a UI? OS X's firewall is disabled by default. Where's the outcry? -- Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Poll: How users use DNF
Dear users of YUM and DNF, I'm writing to you regarding a request for your feedback. I would be very grateful if you could send me a brief description of how you use YUM or DNF currently or how would you like to use it. I am particularly interested in the occurrences of dnf/yum install calls in your scripts. What does these scripts do and what do they expect when they call the install command in different situations? Please share with me the use cases, not the description of the install command. Think twice before you share something because I believe it's not as easy as it might seem. As an example I think it might be something like: - I call YUM install, because I want to get given packages into my system and I don't care whether it requires an upgrade or downgrade or what. or - I want to get them there but it should protect me against dangerous operations like downgrades or - I often make typos, so I expect that the program knows what I mean or - it would be nice if it would literally perform the installation; if any of the packages cannot be installed because of any reason, it should fail. Not something like: that's obvious that the install command should never downgrade packages. Please focus on *use cases*. The *real* (non-hypothetical) use cases. Not on the command's name as it might also result in a new command (while preserving the well-known install command together with an appropriate behaviour). I don't mind if you send it offlist (or to another list). I think there is no need to comment on anyone's use case. Every case is valid. Just not every case can be supported. Thank you very much in advance. -- Radek Holý Associate Software Engineer Software Management Team Red Hat Czech -- 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: Workstation Product defaults to wide-open firewall
On 12/09/2014 10:27 AM, Chris Murphy wrote: On Mon, Dec 8, 2014 at 11:59 PM, William B will...@firstyear.id.au wrote: The true crux of this issue is the over complexity that firewalld has brought to fedora, and the fact that a quality UI for managing it does not exist yet. OSX solves this issue by having an on or off button, and a list of applications that are allowed access. When the application first requests access, a prompt is given to add the application to the allow list. Why are we so against such a UI? OS X's firewall is disabled by default. Where's the outcry? A quick search reveals that some people don't like that: https://blog.mozilla.org/nnethercote/2014/06/03/why-do-new-macbooks-ship-with-the-firewall-off-by-default/ http://www.dummies.com/how-to/content/should-you-use-a-firewall-with-os-x-mountain-lion.html http://arstechnica.com/civis/viewtopic.php?p=20420972 Not that I think this has any bearing on the current discussion. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane or...@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On Tue, Dec 9, 2014 at 2:08 AM, Nikos Mavrogiannopoulos n...@redhat.com wrote: On Tue, 2014-12-09 at 17:29 +1030, William B wrote: I just happened to look at the firewalld default settings, and I was not amused when I noticed this: http://pkgs.fedoraproject.org/cgit/firewalld.git/tree/FedoraWorkstation.xml port protocol=udp port=1025-65535/ port protocol=tcp port=1025-65535/ This firewall is a joke! ALL higher ports are wide open! I want to point out that for many home users, going into the future this is worse than it seems. Many of us are just thinking about the local network. Firewalld implements these rules not just for ipv4, but ipv6 too. If you have a low quality home router, that just lets ipv6 traffic in, you aren't just exposed to the whole network, but the whole internet. While ipv6 relies somewhat on well configured router firewalls, we cannot guarantee this. That is compromise. Of course there are untrustworthy LANs. However we shouldn't cripple functionality for users on their trusted lan because there may be few users in a LAN they don't trust. If you are in such a lan, then I'd expect to switch your firewall's zone. If the installer could do that automatically, it would be even better. If the join wifi UI were to accept one piece of additional metadata about the connection it's storing: home, work, friend, public, each connection could be associated with an appropriate firewall zone automatically. And if the AP is insecure, a rule could set the zone to public by default. Typical users don't manually switch firewall zones. They can't even do this on tablet and mobile devices. -- Chris Murphy -- 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: Workstation Product defaults to wide-open firewall
On 9 December 2014 at 10:27, Chris Murphy li...@colorremedies.com wrote: On Mon, Dec 8, 2014 at 11:59 PM, William B will...@firstyear.id.au wrote: The true crux of this issue is the over complexity that firewalld has brought to fedora, and the fact that a quality UI for managing it does not exist yet. OSX solves this issue by having an on or off button, and a list of applications that are allowed access. When the application first requests access, a prompt is given to add the application to the allow list. Why are we so against such a UI? OS X's firewall is disabled by default. Where's the outcry? It was a long time ago and it basically caused it to have extra configurations before it could be 'ok'd' for various corporate and government sites. Not something Fedora Workstation is aiming at. -- Stephen J Smoogen. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Agenda for Env-and-Stacks WG meeting (2014-12-10)
WG meeting will be at 12:00 UTC (07:00 EST, 13:00 Brno, 7:00 Boston, 21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting on Freenode. = Topics = * Follow-ups * languages repositories * SCLs * Chairman for next meeting * Open Floor -- 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: Workstation Product defaults to wide-open firewall
On 09/12/14 18:39, Stephen John Smoogen wrote: On 9 December 2014 at 10:27, Chris Murphy li...@colorremedies.com [cut] OS X's firewall is disabled by default. Where's the outcry? It was a long time ago and it basically caused it to have extra configurations before it could be 'ok'd' for various corporate and government sites. Not something Fedora Workstation is aiming at. Hm... has anyone a feeling about how such entities would react to the current firewall defaults (open for user ports)? Do we care? Cheers! --alec -- 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: Workstation Product defaults to wide-open firewall
On 12/09/2014 11:46 AM, Richard Hughes wrote: I don't think it makes much sense for people to stamp their feet saying "BUT I LIKED THE OLD WAY OF DOING THINGS" when the people leading the workstation product have identified that the old way of doing things just doesn't work for the majority of people. You're probably not in that majority, but that doesn't mean the change is in someway intrinsically flawed. Nor does it mean that the change is intrinsically right! Every pro argument on the list about this has been because "firewalls are hard" for most users. At the same time the release notes are saying that the change is for developers (2.3.3) -- and devoting half of the opening sentence to the media sharing use case. If someone is a developer then they should have a hurdle before opening their potentially dangerous code to the outside world. The media sharing use case is really the crux here, and I appreciate the issues involved. However, instead of turning off the firewall to non-privileged ports, why not create a tool that opens the involved ports that's driven by the user? That seems a much better solution than disabling the firewall to make media sharing easier. If it isn't ready, it should have been pushed to F22. The biggest problem I have with it is that it's a huge security policy change that has a relatively tiny note in the release notes. I know multiple people in my department (developers) will end up with databases, tomcats, rails, and other network-based servers on the open net because they didn't see the notice in the release notes. Personally, I'll just add it to the "poor choices that fedora made that I'll undo at install time" list. -- 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: Workstation Product defaults to wide-open firewall
On 9 December 2014 at 10:46, Alec Leamas leamas.a...@gmail.com wrote: On 09/12/14 18:39, Stephen John Smoogen wrote: On 9 December 2014 at 10:27, Chris Murphy li...@colorremedies.com [cut] OS X's firewall is disabled by default. Where's the outcry? It was a long time ago and it basically caused it to have extra configurations before it could be 'ok'd' for various corporate and government sites. Not something Fedora Workstation is aiming at. Hm... has anyone a feeling about how such entities would react to the current firewall defaults (open for user ports)? Do we care? Same way, and we do not care for this release. Later releases can be dealt with when they come about. In the end, this is a tempest in a teapot. The release is out and it is done. I don't like it, but my yelling and screaming and spitting in an autistic rage did not fix it so its time to move on so that is what I am going to do. -- Stephen J Smoogen. -- 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: Workstation Product defaults to wide-open firewall
On 09/12/14 18:53, Stephen John Smoogen wrote: In the end, this is a tempest in a teapot. The release is out and it is done. I don't like it, but my yelling and screaming and spitting in an autistic rage did not fix it so its time to move on so that is what I am going to do. Amen --alec -- 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: [Test-Announce] Fedora 22 nightly compose 2014-12-08 nominated for testing
On Mon, 2014-12-08 at 19:06 -0800, Adam Williamson wrote: Hi, folks. So after this morning's meeting, I worked today to implement nightly build support in the mediawiki template magic and in relval. We don't yet have the bits to listen out for composes, create the results pages when anaconda packages change, and send out automated announce mails, but we can now create results pages for nightly composes and report results for them using relval. So to kick things off, I've put up the first set of nightly result pages for Fedora 22: Just as a follow-up, testcase-stats is now up for F22 as well: https://www.happyassassin.net/testcase_stats/22/ it should handle the nightly builds correctly and give us an overview of where we're at with test coverage. If it doesn't, send me bug reports :P -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On Tue, 2014-12-09 at 10:19 -0500, Bastien Nocera wrote: - Original Message - Hi, I also thought that the whole points of having Zones etc, was so that we could pick a different zone per network connection, /me too. so if I'm in the office or at home I can say use this zone, if I'm at a coffee shop I can pick a different one etc. Or was this consider too much UI for the normal user? Surely OSX has something to copy from, since they seem to define what a normal user expects. OSX has a firewall integration that I would rank as awful. It's not any better than what we had in Fedora 20 (blocking firewall and a tool to open up ports). Have a look at Windows then. Each time you hook a windows machine to a new network it asks what network this is. Used to be public, home, work. Recently they simplified that and kicked the home / work separation, so it's only public / non-public now. With some explanation along the lines of use public for hotspots, use home for your private network where you want share stuff. Why we can't have something like this? And if you don't want a popup asking, have something in the NetworkManager applet menu, where people can easily find the switch without having to search for it? A [x] allow sharing checkbox? A firewall zone selector? Side Note: For the latter we need to cleanup the zones though. There are *way* to many to choose from, and the names suck big time. WTF is a Fedora$product zone? And wasn't that discussed before on this list? Why do we *still* have this mess? This isn't a side note, IMO. It was one of the major reasons why we chose not to expose users to the concept of zones. In addition to the names being obscure in firewalld (there's a bug filed about that), they also are obscure in Windows. What configuration difference is there between home and work, and how do you explain them without going deeper into technical details? Are there cases where I want to share things in a work environment and not a home environment? IMO there is simply no way around asking the user. Instead of asking the user, we're getting the user to tell us they want to share things. This avoids unnecessary nagging. Make sharing stuff easy (so you can watch your dnla-exported photo/video collection at your smart tv) is a reasonable request. But enabling that by allowing everybody fetch your private photo collection via dnla while you are surfing @ starbucks is a non-starter. This isn't what was implemented. DLNA share will be turned off by default on new networks. In fact, we won't allow any unencrypted services to run when on unencrypted Wi-Fi. cheers, Gerd PS: Seems windows can even identify different wired networks. I've switched my router recently, and windows re-asked what network I'm on. Probably they remember the mac address of the default gateway or something like that. This will be implemented as soon as NetworkManager makes it easier for us to detect different wired connections. For now, all wired connections are considered to be the same one, which could be a problem. Just a reminder that wired detection is always best-effort, unless the switch is using 802.1x (which few do outside of highly secure enterprises). It's trivial for somebody to spoof any mechanism for wired network detection. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Workstation Product defaults to wide-open firewall
On Dec 9, 2014 10:54 AM, Stephen John Smoogen smo...@gmail.com wrote: On 9 December 2014 at 10:46, Alec Leamas leamas.a...@gmail.com wrote: On 09/12/14 18:39, Stephen John Smoogen wrote: On 9 December 2014 at 10:27, Chris Murphy li...@colorremedies.com [cut] OS X's firewall is disabled by default. Where's the outcry? It was a long time ago and it basically caused it to have extra configurations before it could be 'ok'd' for various corporate and government sites. Not something Fedora Workstation is aiming at. Hm... has anyone a feeling about how such entities would react to the current firewall defaults (open for user ports)? Do we care? Same way, and we do not care for this release. Later releases can be dealt with when they come about. In the end, this is a tempest in a teapot. The release is out and it is done. I don't like it, but my yelling and screaming and spitting in an autistic rage did not fix it so its time to move on so that is what I am going to do. -- Stephen J Smoogen. -- This discussion would resolve quickly if we had video proof of your antics, smooge :) But seriously, there's an implication in this thread that there will be work happening to give stuff a path to ask for an open port. Where can we follow along with that effort? Starting with, say, how I might change `nikola runserver` or `django-admin runserver` to ask for the port, and ending with the resulting UI that asks me for approval? If we want actual progress, it doesn't happen because of controversial compromises, or mailing list flamewars, or even GNOME-specific UI responses to dbus signals. We're all here talking about it - let's talk about what would be ideal, and start pointing at the code to make it work. --Pete -- 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: Workstation Product defaults to wide-open firewall
Richard Hughes wrote: So do I! I'm a developer, which spin do I use so that the firewall doesn't get in my way? We can't develop a *product* based around what you specifically want, not me, nor anyone else on this list. If you're a developer, surely you know what a port is and can make a few clicks in firewall-config or system-config-firewall to open it! A developer who can't even figure that out is a HORRIBLE developer! Kevin Kofler -- 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: Tick-tock release cadence?
On Mon, Dec 8, 2014 at 2:18 PM, Brendan Conoboy b...@redhat.com wrote: On 12/04/2014 06:39 AM, Matthew Miller wrote: What do you think? Would this help towards the goals listed above? Would it help _other_ things? What downsides would it bring? It sounds a lot like releasing a new compose of an existing release with updates included in the repository. Why not do that instead? It would be more of a stable midpoint release than a tick-tock, but you get a similar effect without constraining devel. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com [...] +1 It looks like this need is partially met by the live respins. The Fedora 20 live Desktop ISO is among them. http://mirrors.kernel.org/fedora/updates/20/Live/x86_64/ https://alt.fedoraproject.org/pub/alt/live-respins/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
