On 10 December 2014 at 11:47, Bastien Nocera <bnocera@xxxxxxxxxx> wrote: > > > ----- Original Message ----- >> On 10 December 2014 at 00:43, Bastien Nocera <bnocera@xxxxxxxxxx> wrote: >> > >> > >> > ----- Original Message ----- >> >> On 9 December 2014 at 13:47, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> >> >> wrote: >> >> > On Tue, Dec 09, 2014 at 01:11:33PM +0000, 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. >> >> > >> >> >> >> Well that's some good news to come out of this at least. >> >> >> >> > 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....) >> >> > >> >> >> >> Rather time poor at the moment and not a gnome developer >> >> unfortunately. Does rather sound like things like rygel need fixed, >> >> but as I have no intention of ever using it I'm not highly motivated >> >> to do something about it. >> > >> > Just like Reindl you make the mistake of thinking that rygel needs to be >> > fixed >> > or that it's the only service impacted by this scheme. It's not, and it was >> > pointed out in earlier mails. >> > >> >> You're sniping at me now, and making assumptions. So I get to do this, >> please read the fedora code of conduct and be awesome! >> http://fedoraproject.org/code-of-conduct > > Given the amount of time I've thrown into this dead-end thread, I think > I'm already pretty awesome. > >> I have skimmed the links you listed. Like I said, time poor. > > You'll accuse me of being rude again, but if you can't read 3 pages of text > because of the lack of time, maybe spending that time throwing factually > and technically incorrect suggestions on the list shouldn't top of your > TODO list. > Well, there are different levels I suppose. There's, "I don't have time before work to read through three pages of chaff AND COMMENTS in detail." As it turned out the only salient point was in a comment. The rest was pretty irrelevant. There's, "I don't have time in the foreseeable future to spend learning sufficient information about the internals of the various systems to help out with this particular problem." There's, "I used to spend time doing spin QA, but hardware requirements are currently such that I can't virtualise recent releases and don't have time for bare metal testing which may change in the new year." And there's, "I do have time to respond to an email accusing me of making factually and technically incorrect suggestions." Because I'd have walked away at this point if you hadn't felt like padding out your wonderful life coaching. (I note that I'm a saddo who doesn't know how to manage time, but you're awesome for spending time on exactly the same thread.) You answered precisely half of this: >> I see no >> explanation of why rygel needs a random port or why it cannot supply >> that information to firewalld. The same goes for any others that have >> random ports. > > Because that's the mechanism the kernel offers for applications when selecting a > port isn't important, the high port isn't defined by the IANA, and the specs > (DLNA/UPnP in this case) don't force particular ports to be opened. > > Even if we chose static ports for those (or rather port ranges, because if you > have multiple users running, you'd need multiple ports), leaving only those ports > opened wouldn't stop other random applications from choosing those ports to > do something nefarious. You're just limiting the availability of ports without > increasing security. There's no predefined port. So rather than picking one, which would be perfectly possible, any port is asked for. Yes, limiting it to one means only one user can use it without changing those scary settings, but how often is that actually done? Having the other ports closed prevents unintentional exposure and also makes life harder for any nefarious use. But this has all been pointed out already. It also, if I understand correctly, means policies could be shipped with the package. But if you really want to use a random port, this is what firewalld was for, dynamic firewall changes. In fact, a quick google finds this bug: https://bugzilla.redhat.com/show_bug.cgi?id=626188 Which was showing progress towards rygel being able to do that. But it's been closed 'next release', because apparently the ports above 1024 have been unblocked in the firewall. Except this is not a fix, as (as we've learned) it doesn't apply to Fedora other than Desktop and Cloud. That's an interesting move, perhaps you would like to suggest a 'fixed in product X' resolution for use in future. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
