Hi, I have seen this discussed in Fedora marketing but not here or on the devel lists. On Fedora marketing list people agreed that this should be enabled: gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true
Should I post this as a feature request or is it enough just to post it here in this mailing list?
Cheers, Valent.
On Mon, 2008-10-27 at 12:16 +0100, Valent Turkovic wrote:
Hi, I have seen this discussed in Fedora marketing but not here or on the devel lists. On Fedora marketing list people agreed that this should be enabled: gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true
Should I post this as a feature request or is it enough just to post it here in this mailing list?
If I recall correctly this was discussed to death in the GNOME upstream back when it was changed many, many moons ago. You can feel free to take this request to the upstream rather than here in Fedora.
If I were you, though, I wouldn't hold my breath about it. Many people, including myself, have become very accustomed to the spatial browser and its benefits, and would complain just as much if it were reverted.
On Mon, 2008-10-27 at 07:44 -0400, Paul W. Frields wrote:
If I recall correctly this was discussed to death in the GNOME upstream back when it was changed many, many moons ago. You can feel free to take this request to the upstream rather than here in Fedora.
FWIW, it was also recently discussed at the GNOME UI hackfest in Boston
http://live.gnome.org/Boston2008/GUIHackfest
with some real data (e.g. City of Largo of presentation) suggesting that spatial might not be the best default.
You are of course correct that we should normally follow what upstream do; however occasionally we do change some defaults (for better or worse). In this case, I don't think it's clear, a lot of data (the Largo presentation, other distros, just observing users) might suggest the current default is not the best one. I don't know.
Also, this begs the question about how we make decisions what our product looks like. There are many possible answers to that and it always depend on the circumstances; some people suggest voting (!), other suggests following upstream, sometimes a group of people in some committee makes a decision (packaging guidelines; FESCO overrides) and then there's the package-maintainer-gets-to-decide fiefdom (like our firewall maintainer deciding to break .local name resolution (in F9 at least) because of "security" "concerns").
It seems the latter one is how Fedora works; with most maintainers opting to follow upstream. For most packages this is probably fine but for things like the desktop (and user experience in general) it's a little different.
FWIW, I personally don't think any of these are good answers. Often I think it would be useful if we had a good dictator to tell us what to do (in the Linus is the dictator of the kernel way). I don't know. But I think it's a bit broken (not totally though) how things currently work, I think if we changed things a bit we might be creating a better product and we might avoid a lot of the harsh flame wars and exchanges we see on the lists these days. These happens primarily because of some inability to make decisions.
Anyway, no real answers here, only more questions; hopefully food for thought.
If I were you, though, I wouldn't hold my breath about it. Many people, including myself, have become very accustomed to the spatial browser and its benefits, and would complain just as much if it were reverted.
Take it easy, someone just proposed changing the default; I think it's not too much work for you to toggle a single checkbox on a new install. That's what people not using spatial mode (a significant amount including myself) does anyway.
David
On Mon, 2008-10-27 at 10:25 -0400, David Zeuthen wrote:
FWIW, I personally don't think any of these are good answers. Often I think it would be useful if we had a good dictator to tell us what to do (in the Linus is the dictator of the kernel way).
It could work this way, at least for areas of influence. The Desktop SIG has essentially been given carte blanche over the (GNOME) Desktop experience, with the (minor/major) exception of the artwork. If the SIG so decides, they can elect or appoint said dictator who can make all these decisions. That's nearly how the release engineering team works, I'm a dictator however I do have people vote on issues mostly so that I can make sure that we've discussed things to a reasonable majority opinion before I dictate. It's not so much as voting as opinion polling.
On Mon, 2008-10-27 at 10:25 -0400, David Zeuthen wrote:
On Mon, 2008-10-27 at 07:44 -0400, Paul W. Frields wrote:
If I recall correctly this was discussed to death in the GNOME upstream back when it was changed many, many moons ago. You can feel free to take this request to the upstream rather than here in Fedora.
FWIW, it was also recently discussed at the GNOME UI hackfest in Boston
http://live.gnome.org/Boston2008/GUIHackfest
with some real data (e.g. City of Largo of presentation) suggesting that spatial might not be the best default.
This is interesting, thanks.
You are of course correct that we should normally follow what upstream do; however occasionally we do change some defaults (for better or worse). In this case, I don't think it's clear, a lot of data (the Largo presentation, other distros, just observing users) might suggest the current default is not the best one. I don't know.
I don't either -- I presume that the GNOME community makes these choices based on some guiding principles of design and usability. I don't claim to know what those are, though. If they
Also, this begs the question about how we make decisions what our product looks like. There are many possible answers to that and it always depend on the circumstances; some people suggest voting (!), other suggests following upstream, sometimes a group of people in some committee makes a decision (packaging guidelines; FESCO overrides) and then there's the package-maintainer-gets-to-decide fiefdom (like our firewall maintainer deciding to break .local name resolution (in F9 at least) because of "security" "concerns").
It seems the latter one is how Fedora works; with most maintainers opting to follow upstream.
Which, not coincidentally, is in agreement with Fedora's overall objectives. In cases where groups are involved, we usually try to achieve consensus as the easiest way to make decisions, resorting to voting when that doesn't work, or when the decision-making group is itself a representative group.
For most packages this is probably fine but for things like the desktop (and user experience in general) it's a little different.
FWIW, I personally don't think any of these are good answers. Often I think it would be useful if we had a good dictator to tell us what to do (in the Linus is the dictator of the kernel way).
Who exactly do you believe should be that dictator?
Paul W. Frields wrote:
On Mon, 2008-10-27 at 10:25 -0400, David Zeuthen wrote:
FWIW, I personally don't think any of these are good answers. Often I think it would be useful if we had a good dictator to tell us what to do (in the Linus is the dictator of the kernel way).
Who exactly do you believe should be that dictator?
I think many of us remember the times when we had Seth Nickell and Havoc talking "visionary" things about the desktop (even if they weren't exactly "dictators"), it was very useful to see the direction we are going to... any direction. Currently the appearance is we do not have any direction beside "follow upstream", but the upstream (GNOME) pretty much lack the direction also (Havoc and Seth were "upstream").
So yes, I would pretty much like to see someone taking leadership and defining a direction, a "vision". And if he is coherent and active, we may be glad to call him our "dictator".
On Mon, Oct 27, 2008 at 5:26 PM, Nicu Buculei nicu_fedora@nicubunu.ro wrote:
Paul W. Frields wrote:
On Mon, 2008-10-27 at 10:25 -0400, David Zeuthen wrote:
FWIW, I personally don't think any of these are good answers. Often I think it would be useful if we had a good dictator to tell us what to do (in the Linus is the dictator of the kernel way).
Who exactly do you believe should be that dictator?
I think many of us remember the times when we had Seth Nickell and Havoc talking "visionary" things about the desktop (even if they weren't exactly "dictators"), it was very useful to see the direction we are going to... any direction. Currently the appearance is we do not have any direction beside "follow upstream", but the upstream (GNOME) pretty much lack the direction also (Havoc and Seth were "upstream").
So yes, I would pretty much like to see someone taking leadership and defining a direction, a "vision". And if he is coherent and active, we may be glad to call him our "dictator".
Upstream also says that the things they do don't mean that everybody should follow them exactly. Upstream usually does provide some sane defaults but gives the freedom to downstream distibutions to customize them the way distribution's users feel suits them best.
And of course there are things that upstream asks from downstream distrubutions not to change if possible, but some distributions do it anyway.
That is why I understand Nicu that there should be a "benevolent dictator vision".
Valent.
On Mon, 27 Oct 2008, Paul W. Frields wrote:
For most packages this is probably fine but for things like the desktop (and user experience in general) it's a little different.
FWIW, I personally don't think any of these are good answers. Often I think it would be useful if we had a good dictator to tell us what to do (in the Linus is the dictator of the kernel way).
Who exactly do you believe should be that dictator?
Possible answers (though not necessarily an exhaustive list):
(1) Desktop SIG, which jrb and any number of the folks who work for jrb are free to participate in. Most SIGs have someone who is looked to as the leader, and part of that leadership is to make the tough decision.
(2) From the Red Hat side, jrb is the manager of the desktop team, and while I have not idea how he runs his team, I would think that if you need a dictatorial-type of decision to be made, you could always just ask your boss to make it.
(3) Ultimately for anything involving Fedora, it is in the job description of the Fedora Project Leader to be the benevolent dictator. This responsibility is delegated down to the Fedora Board (and in the cases relevant to this list) also to the Desktop SIG and Artwork Team. But none of that changes the fact that *Red Hat* pays the Fedora Project Leader to be the benevolent dictator for anything that carries the Fedora brand.
(4) Package maintainers, as already stated, who can choose to default to upstream if they so desire.
The key to successfully managing the many parallel and overlapping threads of Fedora is not to have DEMOCRACY -- with a few exceptions, I generally agree with davidz's general theme of "voting on stuff isn't the right way to make a decision" -- but to have a decision-making process and chain of command identified so that decisions ultimately do get made.
Then if a certain person dislikes a decision, they should know (a) WHY that decision was made, and (b) WHO made that decision.
Bonus points for the decision makers stating their rationale in public, and for having open discussions leading up to the decision, depending on how important or complicated the decision is.
--Max
On Mon, 27 Oct 2008, Max Spevack wrote:
Bonus points for the decision makers stating their rationale in public, and for having open discussions leading up to the decision, depending on how important or complicated the decision is.
After reading Nicu's reply, I also want to add that my analysis does not touch on any questions of decision-making or leadership in the upstream GNOME project that could then filter down into Fedora to package maintainers or the Desktop SIG. As I do not actively participate in the upstream GNOME community, I am not in a place to comment on how it functions.
--Max
Den 27. okt. 2008 17.00 skrev Paul W. Frields stickster@gmail.com:
Who exactly do you believe should be that dictator?
I, for one, would be happy to push for davidz to be the "desktop dictator", he is passionate about the Linux desktop, informed and willing to work to make the situation better. Additionally he is visionary and has a long track record of bringing improvements to my desktop. Many of the qualities that would be beneficial to such a position as the guiding light in my opinion.
That being said, it will probably end up needing to be a small group of people with a transparent workflow, the Linux desktop is a large place, ever expanding to new devices and vistas. It seems unreasonable to assume one person can fully grasp it all but we would still benefit from passionate guidance and a firm plan for the future. Even Linus has subsystem maintainers he trusts to do good work, surely that system will map nicely to the desktop.
* This message paid for by the commitee of concerned fedorains in favor of David Zeuthern for grand high poobah *
- David Nielsen
On Tue, 2008-10-28 at 00:21 +0100, David Nielsen wrote:
I, for one, would be happy to push for davidz to be the "desktop dictator",
Thanks for the, uh, endorsement. But I don't think I'm the right person; first of all I've already got a ton of commitments (the mythical dictator position would be a full time job I think), second we probably need someone who's, uh, more, let's just say, more patient and nicer than me on mailing lists (I know I can come across as a real asshole). But I'd be more than happy to keep the dictator(s) honest!
Paul W. Frields wrote:
Who exactly do you believe should be that dictator?
It's hard to say, I tried to allude in my message that I raised more questions than I answered (and I certainly wasn't pointing to myself for this mythical position).
So I think this thread shows we need to figure this out; it's pretty clear that the status quo where the combined desktop livecd product is everyones responsibility (through maintaining their own packages) means that it's no-ones responsibility. We have a lot of low-hanging fruit just *waiting* to be picked up (the firewall problem is one such) but typically such work requires coordination, education and banner carrying across multiple areas both inside and outside the desktop live cd space.
Answers on a post card (because I'm leaving on a jet plane early tomorrow).
David
2008/10/28 David Zeuthen davidz@redhat.com
On Tue, 2008-10-28 at 00:21 +0100, David Nielsen wrote:
I, for one, would be happy to push for davidz to be the "desktop dictator",
Thanks for the, uh, endorsement. But I don't think I'm the right person; first of all I've already got a ton of commitments (the mythical dictator position would be a full time job I think), second we probably need someone who's, uh, more, let's just say, more patient and nicer than me on mailing lists (I know I can come across as a real asshole). But I'd be more than happy to keep the dictator(s) honest!
No worries, Linus, after whom this idea was molded, isn't exactly known for his diplomacy and people skills either - I think it would be a downright requirement for the post to be sort of dick when called for. I know you are busy and regardless of Fedora ever adopting such a position it's likely there would be a great deal of interaction seeing as all our desktops are belong to hal/devicekit. The reason to make such an endorsement is mostly because whenever such an idea is proposed the only responses seem to go in the direction of the impossibility based on who should be appointed.. giving an example of the qualities such a position would entail seems more productive.
- David
David Zeuthen wrote:
So I think this thread shows we need to figure this out; it's pretty clear that the status quo where the combined desktop livecd product is everyones responsibility (through maintaining their own packages) means that it's no-ones responsibility. We have a lot of low-hanging fruit just *waiting* to be picked up (the firewall problem is one such) but typically such work requires coordination, education and banner carrying across multiple areas both inside and outside the desktop live cd space.
I'm wondering if it would be useful to hold a Fedora-specific desktop summit type of meeting to first come up with the Fedora-specific desktop vision for the desktop livecd product, then to hash out the projects and their respective work items needed to achieve the vision (or at least a first phase of it.) Post-meeting, I think you would need at least one if not more champions for the whole project (I don't like the term dictator) to keep things moving forward and to motivate the folks working on tasks in the plan.
We did something like this for the spins site at the last FUDcon and I think the meeting was really successful in developing a common shared vision for where we wanted to project to go. I think we came into the room having some very different ideas, and walked away from the room in agreement of where we wanted to be. Although that particular project is stalled somewhat because there aren't many people working on it at the moment, because we have that shared vision we do know what we have to do (it's just an issue of time/manpower atm).
Is this situation a simple manpower issue? It seems not and, at least looking at this thread, there may not even be a shared vision for the desktop livecd. There appears to be no single vision that is really documented/written out/demonstrated anywhere public (if there is though, great!) There seem to be many that perhaps live only in individual posters' minds. (And when posters write out their visions on this mailing list I find it hard to even focus on the ideas because of the poor / jarringly hostile delivery)
I think maybe some kind of vision document would go a long way towards moving forward though. What are our shortcomings now => where we should be. What are the low-hanging fruit you mentioned? Are they listed out or described anywhere? We need a compelling story to tell. Could the ideal Fedora desktop user experience be storyboarded out, maybe have a few storyboards drawn out for scenarios under a few themes, such as security, content sharing, backup/storage, communication, upgrading, etc.
Anyway this is just an idea, *please* don't flame me. I am posting this in hope that it might spark some more (hopefully better) ideas for moving forward.
Thanks, ~m
On Mon, Oct 27, 2008 at 8:01 PM, Mairin Duffy duffy@fedoraproject.org wrote:
David Zeuthen wrote:
So I think this thread shows we need to figure this out; it's pretty clear that the status quo where the combined desktop livecd product is everyones responsibility (through maintaining their own packages) means that it's no-ones responsibility. We have a lot of low-hanging fruit just *waiting* to be picked up (the firewall problem is one such) but typically such work requires coordination, education and banner carrying across multiple areas both inside and outside the desktop live cd space.
I'm wondering if it would be useful to hold a Fedora-specific desktop summit type of meeting to first come up with the Fedora-specific desktop vision for the desktop livecd product, then to hash out the projects and their respective work items needed to achieve the vision (or at least a first phase of it.) Post-meeting, I think you would need at least one if not more champions for the whole project (I don't like the term dictator) to keep things moving forward and to motivate the folks working on tasks in the plan.
We did something like this for the spins site at the last FUDcon and I think the meeting was really successful in developing a common shared vision for where we wanted to project to go. I think we came into the room having some very different ideas, and walked away from the room in agreement of where we wanted to be. Although that particular project is stalled somewhat because there aren't many people working on it at the moment, because we have that shared vision we do know what we have to do (it's just an issue of time/manpower atm).
Is this situation a simple manpower issue? It seems not and, at least looking at this thread, there may not even be a shared vision for the desktop livecd. There appears to be no single vision that is really documented/written out/demonstrated anywhere public (if there is though, great!) There seem to be many that perhaps live only in individual posters' minds. (And when posters write out their visions on this mailing list I find it hard to even focus on the ideas because of the poor / jarringly hostile delivery)
I think maybe some kind of vision document would go a long way towards moving forward though. What are our shortcomings now => where we should be. What are the low-hanging fruit you mentioned? Are they listed out or described anywhere? We need a compelling story to tell. Could the ideal Fedora desktop user experience be storyboarded out, maybe have a few storyboards drawn out for scenarios under a few themes, such as security, content sharing, backup/storage, communication, upgrading, etc.
Anyway this is just an idea, *please* don't flame me. I am posting this in hope that it might spark some more (hopefully better) ideas for moving forward.
Well I think the first question is what is a desktop and what do we call them in various environments. My typical environment makes me an ideal candidate for clean widgets, but not for using avahi for anything beyond finding corporate approved printers and file-shares. That isn't what the home user who is looking for another gig of Daily Show episodes wants.
On Mon, 2008-10-27 at 22:01 -0400, Mairin Duffy wrote:
David Zeuthen wrote:
So I think this thread shows we need to figure this out; it's pretty clear that the status quo where the combined desktop livecd product is everyones responsibility (through maintaining their own packages) means that it's no-ones responsibility. We have a lot of low-hanging fruit just *waiting* to be picked up (the firewall problem is one such) but typically such work requires coordination, education and banner carrying across multiple areas both inside and outside the desktop live cd space.
I'm wondering if it would be useful to hold a Fedora-specific desktop summit type of meeting to first come up with the Fedora-specific desktop vision for the desktop livecd product, then to hash out the projects and their respective work items needed to achieve the vision (or at least a first phase of it.) Post-meeting, I think you would need at least one if not more champions for the whole project (I don't like the term dictator) to keep things moving forward and to motivate the folks working on tasks in the plan.
We did something like this for the spins site at the last FUDcon and I think the meeting was really successful in developing a common shared vision for where we wanted to project to go. I think we came into the room having some very different ideas, and walked away from the room in agreement of where we wanted to be. Although that particular project is stalled somewhat because there aren't many people working on it at the moment, because we have that shared vision we do know what we have to do (it's just an issue of time/manpower atm).
[...snip...]
We have a FUDCon coming up in January, in Boston where the majority of the Desktop team resides. That would be an ideal location and time for this sort of summit!
Den 28. okt. 2008 12.44 skrev Paul W. Frields stickster@gmail.com:
We have a FUDCon coming up in January, in Boston where the majority of the Desktop team resides. That would be an ideal location and time for this sort of summit!
I would be a little concerned with relying to heavily on FUDcon for such work, Fedora is a big project, many contributors spread across the globe, many of whom would probably like their voice heard or have ideas they wish to share. A lot of these people will not be able to go and partake in the talks for simple reasons of time and/or money. Most of the time we don't even get good video or audio of all the proceedings afterwards so it's hard to traceback what the rationale for a decision is or to see what other vistas were explored. As such I would be afraid a high reliance on FUDcon for this work would lead to a lack of transparency in our process. I would hate for this to become Moses coming down from the mountain carrying specs set in stone without accompanying notes.
- David
On Tue, 28 Oct 2008, David Nielsen wrote:
I would be a little concerned with relying to heavily on FUDcon for such work, Fedora is a big project, many contributors spread across the globe, many of whom would probably like their voice heard or have ideas they wish to share. A lot of these people will not be able to go and partake in the talks for simple reasons of time and/or money. Most of the time we don't even get good video or audio of all the proceedings afterwards so it's hard to traceback what the rationale for a decision is or to see what other vistas were explored. As such I would be afraid a high reliance on FUDcon for this work would lead to a lack of transparency in our process. I would hate for this to become Moses coming down from the mountain carrying specs set in stone without accompanying notes.
Then don't call it a Summit. Call it an "opportunity for the RH Desktop team to talk with some number of the other Fedora people in order to further mutual understanding". :)
I think Paul's point is that if some amount of Fedora is going to be right in Red Hat's engineering backyard, where a lot of the RH Desktop team is, that is an opportunity that should be seized to do SOMETHING rather than ignored.
--Max
David Nielsen wrote:
Den 28. okt. 2008 12.44 skrev Paul W. Frields stickster@gmail.com:
We have a FUDCon coming up in January, in Boston where the majority of the Desktop team resides. That would be an ideal location and time for this sort of summit!
I would be a little concerned with relying to heavily on FUDcon for such work, Fedora is a big project, many contributors spread across the globe, many of whom would probably like their voice heard or have ideas they wish to share. A lot of these people will not be able to go and partake in the talks for simple reasons of time and/or money. Most of the time we don't even get good video or audio of all the proceedings afterwards so it's hard to traceback what the rationale for a decision is or to see what other vistas were explored. As such I would be afraid a high reliance on FUDcon for this work would lead to a lack of transparency in our process. I would hate for this to become Moses coming down from the mountain carrying specs set in stone without accompanying notes.
I would rather the vision be developed in an open public way than live solely in the mind of some dictator who optionally (as a "bonus") would actually communicate and work with other community members.
Unfortunately it isn't possible for everyone who wants to participate to be able to go to a physical meeting, but I know for the spins meeting we did at the last FUDcon we were very careful to make sure we took very good notes [1] and blogged about it as well.
Once the story is developed it's easier to tell it and add on to it I think. But developing it is a big step I'm not sure of any better way to get done than a physical brainstorming meeting.
~m
On Tue, 2008-10-28 at 09:21 -0400, Máirín Duffy wrote:
David Nielsen wrote:
Den 28. okt. 2008 12.44 skrev Paul W. Frields stickster@gmail.com:
We have a FUDCon coming up in January, in Boston where the majority of the Desktop team resides. That would be an ideal location and time for this sort of summit!
I would be a little concerned with relying to heavily on FUDcon for such work, Fedora is a big project, many contributors spread across the globe, many of whom would probably like their voice heard or have ideas they wish to share. A lot of these people will not be able to go and partake in the talks for simple reasons of time and/or money. Most of the time we don't even get good video or audio of all the proceedings afterwards so it's hard to traceback what the rationale for a decision is or to see what other vistas were explored. As such I would be afraid a high reliance on FUDcon for this work would lead to a lack of transparency in our process. I would hate for this to become Moses coming down from the mountain carrying specs set in stone without accompanying notes.
I would rather the vision be developed in an open public way than live solely in the mind of some dictator who optionally (as a "bonus") would actually communicate and work with other community members.
Unfortunately it isn't possible for everyone who wants to participate to be able to go to a physical meeting, but I know for the spins meeting we did at the last FUDcon we were very careful to make sure we took very good notes [1] and blogged about it as well.
Once the story is developed it's easier to tell it and add on to it I think. But developing it is a big step I'm not sure of any better way to get done than a physical brainstorming meeting.
~m
Hear, hear. We have to keep in mind that conversations that happen at FUDCon aren't closed universes where there's no input beforehand and no follow-up afterward. They are a good place to collect a lot of input *representative* of the community at one time, quickly and without the equally (albeit differently) obtrusive communication methods of email and IRC. After one of these group meetings, organizers should (and do) carry those conversations to the larger community for more comment and direction.
This *did* work very well with the spins meeting, and as Mo writes, that meeting was well documented and conducted in an extremely open and transparent way. The people who attend FUDCon are a highly representative cross-section of the community at large, with viewpoints across the board on a variety of issues. Getting that spectrum of opinion documented at one of these meetings is a very effective way of moving Fedora forward, but always with an eye toward allowing people everywhere to add dimensions to the discussion as we go.
Announcing FUDCon sessions in advance also gives everyone, attending or not, the opportunity to discuss key issues before the actual physical meeting. That's exactly why, if there's a desire to promote a more targeted desktop spin, we're suggesting the teams involved make that sort of commitment or announcement now. That way, the community can fully participate as much as it desires, and those teams can collect input as needed to have a fruitful session at FUDCon.
Hi,
You are of course correct that we should normally follow what upstream do; however occasionally we do change some defaults (for better or worse). In this case, I don't think it's clear, a lot of data (the Largo presentation, other distros, just observing users) might suggest the current default is not the best one. I don't know
This isn't the sort of thing we should diverge from upstream on. If it makes sense to change it for Fedora, we should lobby to get it changed upstream as well.
This case in particular is silly, since Alex (who wrote spatial mode) is upstream GNOME and downstream Fedora.
--Ray
On Mon, 2008-10-27 at 12:18 -0400, Ray Strode wrote:
This case in particular is silly, since Alex (who wrote spatial mode) is upstream GNOME and downstream Fedora.
You are missing the point that the sums of the bits (our product) is larger than the bits itself (each package). I posited in my original mail that we can create a better product if we have a dictator (or group of dictators) that makes decisions. In other words, we need to move away from the model where every package maintainer maintains his own fiefdom. It's counter productive to the point that it cripples the product (e.g. the firewall example I gave earlier).
(FWIW, in this particular case I see little chance of us actually switching to browser mode. E.g. with the dictator candidates I have in mind, I don't see it happening. I guess I'm just one of them odd-ball browser mode persons.)
This isn't the sort of thing we should diverge from upstream on. If it makes sense to change it for Fedora, we should lobby to get it changed upstream as well.
Sure. But as I outlined in my original mail this is not always possible. But it's a nice goal.
David
On Mon, Oct 27, 2008 at 5:58 PM, David Zeuthen davidz@redhat.com wrote:
On Mon, 2008-10-27 at 12:18 -0400, Ray Strode wrote:
This case in particular is silly, since Alex (who wrote spatial mode) is upstream GNOME and downstream Fedora.
You are missing the point that the sums of the bits (our product) is larger than the bits itself (each package). I posited in my original mail that we can create a better product if we have a dictator (or group of dictators) that makes decisions. In other words, we need to move away from the model where every package maintainer maintains his own fiefdom. It's counter productive to the point that it cripples the product (e.g. the firewall example I gave earlier).
Aaaahhhhh! That is why I can't open my corporate local pages!!! I thought I was going nuts! I went from FC6 to F10 (rawhide) and I thought this was some rawhide bug or miss configuration on my part.
How do I enable .local pages to work again?
Cheers, Valent.
On Mon, 2008-10-27 at 19:04 +0100, Valent Turkovic wrote:
Aaaahhhhh! That is why I can't open my corporate local pages!!! I thought I was going nuts! I went from FC6 to F10 (rawhide) and I thought this was some rawhide bug or miss configuration on my part.
How do I enable .local pages to work again?
Just disable the firewall (service iptables stop)? That's what I do anyway. IMNSHO, these days the firewall is a relic from the 1990's era. It breaks at least mDNS (e.g. .local name resolution), gnome-user-share, banshee/rhythmbox etc. music sharing. I also think we should also disable the firewall for the desktop spin.
David
On Mon, Oct 27, 2008 at 7:13 PM, David Zeuthen davidz@redhat.com wrote:
On Mon, 2008-10-27 at 19:04 +0100, Valent Turkovic wrote:
Aaaahhhhh! That is why I can't open my corporate local pages!!! I thought I was going nuts! I went from FC6 to F10 (rawhide) and I thought this was some rawhide bug or miss configuration on my part.
How do I enable .local pages to work again?
Just disable the firewall (service iptables stop)? That's what I do anyway. IMNSHO, these days the firewall is a relic from the 1990's era. It breaks at least mDNS (e.g. .local name resolution), gnome-user-share, banshee/rhythmbox etc. music sharing. I also think we should also disable the firewall for the desktop spin.
David
When I suggested only for ipv6iptables (not fully understanding it) to be disabled for Desktop spin I got trashed on devel mailing list, so good luck with that ;)
Valent.
On Mon, 2008-10-27 at 19:19 +0100, Valent Turkovic wrote:
Just disable the firewall (service iptables stop)? That's what I do anyway. IMNSHO, these days the firewall is a relic from the 1990's era. It breaks at least mDNS (e.g. .local name resolution), gnome-user-share, banshee/rhythmbox etc. music sharing. I also think we should also disable the firewall for the desktop spin.
DavidWhen I suggested only for ipv6iptables (not fully understanding it) to be disabled for Desktop spin I got trashed on devel mailing list, so good luck with that ;)
These are people that are probably happy about the current user experience and for whom iptables(8) and system-config-firewall probably are the right tools. And if you run a server, these tools may (or may not but I digress) be the right answer.
However, for the desktop, the 1990s called and they want their firewall back. And we should comply since today the desktop is completely broken when it comes to file/music sharing. It's ironic isn't it? We go through all this effort to implement this stuff (Lennart with .local resolution in Avahi, others like Jon McCann for DAAP support in RB, Alex and Bastien for file sharing) and leave broken in the default install? It's ridiculous!
(Of course we are not going to just do "-iptables" in the Desktop kickstart file, we need to properly assess the situation. Today, unlike the 1990s, we have the ability to confine services with things like SELinux. We could restrict access to local link only (mDNS would work, wide area DNS-SD wouldn't work which is fine) in the default install. We have stack smashing protection. Privilege separation. Etc. It's not exactly rocket science to do this (but not trivial either); someone just needs to sit down and work out a threat assessment, figure out what changes we need and then just do it.)
David
On Mon, 2008-10-27 at 14:13 -0400, David Zeuthen wrote:
On Mon, 2008-10-27 at 19:04 +0100, Valent Turkovic wrote:
Aaaahhhhh! That is why I can't open my corporate local pages!!! I thought I was going nuts! I went from FC6 to F10 (rawhide) and I thought this was some rawhide bug or miss configuration on my part.
How do I enable .local pages to work again?
Just disable the firewall (service iptables stop)? That's what I do anyway. IMNSHO, these days the firewall is a relic from the 1990's era. It breaks at least mDNS (e.g. .local name resolution), gnome-user-share, banshee/rhythmbox etc. music sharing. I also think we should also disable the firewall for the desktop spin.
That's outrageously dangerous. And given how little experience you have maintaining systems or networks I'd say your opinion is very humble indeed.
Please don't give dangerous and costly advice like this.
-sv
On Mon, 2008-10-27 at 14:50 -0400, seth vidal wrote:
That's outrageously dangerous. And given how little experience you have maintaining systems or networks I'd say your opinion is very humble indeed.
(Awesome. Maybe I should make statements about your experience too. Because I mean, I don't know you very well either and talk is cheap.)
Please don't give dangerous and costly advice like this.
Hardly advice if it's suffixed with a question mark? Maybe. Anyway, see my other message; maybe I should have elaborated in the original message.
David
On Mon, 2008-10-27 at 15:16 -0400, David Zeuthen wrote:
On Mon, 2008-10-27 at 14:50 -0400, seth vidal wrote:
That's outrageously dangerous. And given how little experience you have maintaining systems or networks I'd say your opinion is very humble indeed.
(Awesome. Maybe I should make statements about your experience too. Because I mean, I don't know you very well either and talk is cheap.)
If you'd like to have a CV-off with regard to security awareness and actual experience maintaining and securing systems and networks, I'd be happy to do so.
Disabling firewalls on individual systems be they desktops or servers is a BAD idea. Full stop.
Please don't give dangerous and costly advice like this.
Hardly advice if it's suffixed with a question mark? Maybe. Anyway, see my other message; maybe I should have elaborated in the original message.
I wanted to make sure there was no doubt that disabling firewalls is NOT something anyone should do.
-sv
Hi,
On Mon, Oct 27, 2008 at 3:25 PM, seth vidal skvidal@fedoraproject.org wrote:
I wanted to make sure there was no doubt that disabling firewalls is NOT something anyone should do.
There are different cases. Having the firewall on in every case is a simple story, but it does break the user experience for e.g. the "unmanaged home network, behind Linksys router" case. This is a rather common scenario for the kind of audience we would like to target with the Fedora desktop.
While I personally just turn the firewall off and was considering advocating that, one scenario we should consider is "public coffee shop with wifi". What Windows Vista does is prompt whenever you connect to a new network whether it's "home" or not. I assume if you click "not home" (I forget what the option's called), it enables the firewall fully. If you click "Home" it's either off or more permissive. Something like that would need NetworkManager integration.
Anyways, were we to consider this for F11 I'd suggest a feature page with rational thought and analysis (as opposed to assertions and resume comparisons).
On Mon, 2008-10-27 at 15:42 -0400, Colin Walters wrote:
Hi,
On Mon, Oct 27, 2008 at 3:25 PM, seth vidal skvidal@fedoraproject.org wrote:
I wanted to make sure there was no doubt that disabling firewalls is NOT something anyone should do.
There are different cases. Having the firewall on in every case is a simple story, but it does break the user experience for e.g. the "unmanaged home network, behind Linksys router" case. This is a rather common scenario for the kind of audience we would like to target with the Fedora desktop.
While I personally just turn the firewall off and was considering advocating that, one scenario we should consider is "public coffee shop with wifi". What Windows Vista does is prompt whenever you connect to a new network whether it's "home" or not. I assume if you click "not home" (I forget what the option's called), it enables the firewall fully. If you click "Home" it's either off or more permissive. Something like that would need NetworkManager integration.
Making the user choose to turn off the firewall or enable specific ports(or port ranges) is reasonable. Making the default be no firewall is not reasonable.
-sv
On Mon, 2008-10-27 at 15:42 -0400, Colin Walters wrote:
While I personally just turn the firewall off and was considering advocating that, one scenario we should consider is "public coffee shop with wifi". What Windows Vista does is prompt whenever you connect to a new network whether it's "home" or not. I assume if you click "not home" (I forget what the option's called), it enables the firewall fully. If you click "Home" it's either off or more permissive. Something like that would need NetworkManager integration.
This sounds like a good idea. But it's prudent to note this is not about security, it's about privacy: making sure you don't share stuff with people you don't know.
We should strive to make Fedora secure by default. With good architecture and design (and things like SELinux), this is indeed possible as I noted with the notes about having SELinux integration for gnome-user-share. This is much better than our current setup where virtually everyone ends up turning off the firewall just to make their computer work.
Anyways, were we to consider this for F11 I'd suggest a feature page with rational thought and analysis (as opposed to assertions and resume comparisons).
I don't think anyone disagrees with that. We just need someone to own this task, execute and deliver.
David
On Mon, 2008-10-27 at 15:25 -0400, seth vidal wrote:
If you'd like to have a CV-off with regard to security awareness and actual experience maintaining and securing systems and networks, I'd be happy to do so.
This is classical. Didn't they teach you that bad security is worse than no security? Here's the thing: today the default install of the desktop is broken when it comes to file sharing. It's kinda hard to disagree with that, so I'm going to go ahead and assume you at least agree with that.
Hence, if people want to share files using, say, Rhythmbox (and they do), they are left with either
1. Turning of the firewall 2. Configuring iptables(8) or using system-config-firewall
Now, let me explain to you how RB/Banshee/gnome-user-share works. They allocate a random high port number. Now, before you complain that you think this in broken you have to understand why this is so.
The programs have to do this because you may have several sessions or instances running. So in general you can't really predict the port number (or even range) to use since the user may add new services that share stuff on the network.
So in general 2. won't really work (because you'd have to update it dynamically) so users of course resort to 1. Wow, what's that thing going out the window? That other useful stuff that we might have configured the iptables(8) stack with except for blocking ports.
Also, the user interface of both iptables(8) and system-config-firewall is useless and scary. Even for me. Thus, people are left with doing 1. Lose.
But then again, I don't have that CV saying I know about security (or maybe I do and it's mere existence is classified).
Disabling firewalls on individual systems be they desktops or servers is a BAD idea. Full stop.
Your opinion is noted. I respectfully disagree. I'd suggest to look at how current malware (including Skype) works. It would probably also be useful for you to realize just how ubiquitous the HTTP protocol is and what kind of users it has (hint, more than HTML pages).
(FWIW, for a long time my position was that we should just have an system API to allow trusted apps to poke hole in the local firewall (after determining it's port number) after user confirmation via things like PolicyKit. This can be done in a secure way most of the time because the actual program for sharing doesn't link to things like GTK+. E.g. it can be made secure the same way setuid binaries are secure. But I now think that's a terrible user experience plus I also think our current "firewall" is nothing more than snake oil.)
I wanted to make sure there was no doubt that disabling firewalls is NOT something anyone should do.
No, you wanted to make people aware of your _opinion_. Of which quite a few people, including yours truly, disagree.
David
On Mon, Oct 27, 2008 at 03:53:30PM -0400, David Zeuthen wrote:
Hence, if people want to share files using, say, Rhythmbox (and they do), they are left with either
- Turning of the firewall
- Configuring iptables(8) or using system-config-firewall
Now, let me explain to you how RB/Banshee/gnome-user-share works. They allocate a random high port number. Now, before you complain that you think this in broken you have to understand why this is so.
The programs have to do this because you may have several sessions or instances running. So in general you can't really predict the port number (or even range) to use since the user may add new services that share stuff on the network.
So in general 2. won't really work (because you'd have to update it dynamically) so users of course resort to 1. Wow, what's that thing going out the window? That other useful stuff that we might have configured the iptables(8) stack with except for blocking ports.
But dynamical ports are not new to iptables, lots of protocols, be that rpc, h323 or even p-o-d passive ftp need them and conntrack/pom rectify the `static firewall' view.
I haven't followed up the latest netfilter developments, but I know there is even a userspace lib for registering such connections. Maybe RB/mDNS and friends just need a pom `plugin'.
Note that just as you turn off iptables and prefer selinux, I do that the other way around, as my selinux foo is less than desirable. I guess both of us are not really doing The Right Thing, but sometimes time matters.
On Mon, Oct 27, 2008 at 10:45:38PM +0200, Axel Thimm wrote:
But dynamical ports are not new to iptables, [...] even p-o-d passive ftp need them [...]
Actually I meant active ftp. While passive ftp also negotiates dynamical ports the non-trivial firewall setup is when the server tries to connect to a seemingless random port within the secured IP range.
On Mon, 27.10.08 22:45, Axel Thimm (Axel.Thimm@ATrpms.net) wrote:
On Mon, Oct 27, 2008 at 03:53:30PM -0400, David Zeuthen wrote:
Hence, if people want to share files using, say, Rhythmbox (and they do), they are left with either
- Turning of the firewall
- Configuring iptables(8) or using system-config-firewall
Now, let me explain to you how RB/Banshee/gnome-user-share works. They allocate a random high port number. Now, before you complain that you think this in broken you have to understand why this is so.
The programs have to do this because you may have several sessions or instances running. So in general you can't really predict the port number (or even range) to use since the user may add new services that share stuff on the network.
So in general 2. won't really work (because you'd have to update it dynamically) so users of course resort to 1. Wow, what's that thing going out the window? That other useful stuff that we might have configured the iptables(8) stack with except for blocking ports.
But dynamical ports are not new to iptables, lots of protocols, be that rpc, h323 or even p-o-d passive ftp need them and conntrack/pom rectify the `static firewall' view.
But all those protocols start the connection with a well known port and then hand things off to a dynamic port. If you use truely random ports than iptables needs to sense what kind of protocol something is based on the packet contents. Which security-wise is a joke, and hence the whole idea makes no sense.
I haven't followed up the latest netfilter developments, but I know there is even a userspace lib for registering such connections. Maybe RB/mDNS and friends just need a pom `plugin'.
The Linux kernel already has an API for that. It's called listen().
Lennart
On Mon, Oct 27, 2008 at 09:55:56PM +0100, Lennart Poettering wrote:
But dynamical ports are not new to iptables, lots of protocols, be that rpc, h323 or even p-o-d passive ftp need them and conntrack/pom rectify the `static firewall' view.
But all those protocols start the connection with a well known port and then hand things off to a dynamic port. If you use truely random ports than iptables needs to sense what kind of protocol something is based on the packet contents. Which security-wise is a joke, and hence the whole idea makes no sense.
And there are services that use truely random ports? E.g. w/o any handshaking or negotiation about these ports by well-defined processes? Why do we have mDNS/DNS-SD/SSDP for?
Just like FTP negotiates the `truely random' ports, so do the zeroconf techniques with ips/ports/services.
iptables/netfilter already has intelligent agents to parse the passing packages for needed dynamical firewall configration. Just check it out, and maybe you'll rethink about the netfilter project. :)
I haven't followed up the latest netfilter developments, but I know there is even a userspace lib for registering such connections. Maybe RB/mDNS and friends just need a pom `plugin'.
The Linux kernel already has an API for that. It's called listen().
Cool, so any local non-priviledged process could open up holes in the firewall above ports 1024 as it pleases w/o the user even noticing.
Why not remove password protection from accounts while we are at it? ;)
On Mon, 27.10.08 23:08, Axel Thimm (Axel.Thimm@ATrpms.net) wrote:
On Mon, Oct 27, 2008 at 09:55:56PM +0100, Lennart Poettering wrote:
But dynamical ports are not new to iptables, lots of protocols, be that rpc, h323 or even p-o-d passive ftp need them and conntrack/pom rectify the `static firewall' view.
But all those protocols start the connection with a well known port and then hand things off to a dynamic port. If you use truely random ports than iptables needs to sense what kind of protocol something is based on the packet contents. Which security-wise is a joke, and hence the whole idea makes no sense.
And there are services that use truely random ports? E.g. w/o any handshaking or negotiation about these ports by well-defined processes? Why do we have mDNS/DNS-SD/SSDP for?
So you are suggesting that a firewall should automatically whitelist all ports that are announced via mDNS on the network? Wow. That it is certainly one hell of a good idea. Oh my.
Are you sure you really understand what "security" means?
"Security" certainly doesn't mean whitelisting everything that someone likes to announce on the network via mDNS/DNS-SD.
I haven't followed up the latest netfilter developments, but I know there is even a userspace lib for registering such connections. Maybe RB/mDNS and friends just need a pom `plugin'.
The Linux kernel already has an API for that. It's called listen().
Cool, so any local non-priviledged process could open up holes in the firewall above ports 1024 as it pleases w/o the user even noticing.
Yes. Absolutely. If he wants to use an app he will circumvent the fw anyway. And hence the fw is pointless and it would be far smoother to allow this kind of operation without nagging.
Why not remove password protection from accounts while we are at it? ;)
Hmm, so you did have a clown for breakfast, didn't you?
Lennart
On Mon, Oct 27, 2008 at 10:27:20PM +0100, Lennart Poettering wrote:
On Mon, 27.10.08 23:08, Axel Thimm (Axel.Thimm@ATrpms.net) wrote:
On Mon, Oct 27, 2008 at 09:55:56PM +0100, Lennart Poettering wrote:
But dynamical ports are not new to iptables, lots of protocols, be that rpc, h323 or even p-o-d passive ftp need them and conntrack/pom rectify the `static firewall' view.
But all those protocols start the connection with a well known port and then hand things off to a dynamic port. If you use truely random ports than iptables needs to sense what kind of protocol something is based on the packet contents. Which security-wise is a joke, and hence the whole idea makes no sense.
And there are services that use truely random ports? E.g. w/o any handshaking or negotiation about these ports by well-defined processes? Why do we have mDNS/DNS-SD/SSDP for?
So you are suggesting that a firewall should automatically whitelist all ports that are announced via mDNS on the network? Wow. That it is certainly one hell of a good idea. Oh my.
No, just like the people using active FTP mode never implicitely suggested this either. But if *you* are annoyed for your rhythmbox not automatically sharing its files you could use this mechanism.
Are you sure you really understand what "security" means?
I do, but it's funny to be asked by the person that suggests whitelisting everything, e.g. removing the firewall completely.
"Security" certainly doesn't mean whitelisting everything that someone likes to announce on the network via mDNS/DNS-SD.
It's nice you realize this. But you suggested using listen(2) instead for this purpose in previous mails ...
Anyway it's glad to see a change in mind.
I haven't followed up the latest netfilter developments, but I know there is even a userspace lib for registering such connections. Maybe RB/mDNS and friends just need a pom `plugin'.
The Linux kernel already has an API for that. It's called listen().
Cool, so any local non-priviledged process could open up holes in the firewall above ports 1024 as it pleases w/o the user even noticing.
Yes. Absolutely. If he wants to use an app he will circumvent the fw anyway. And hence the fw is pointless and it would be far smoother to allow this kind of operation without nagging.
So will the superuser do with selinux and any other security feature. Is the consequence to not even ship it or enable it? Not really.
Why not remove password protection from accounts while we are at it? ;)
Hmm, so you did have a clown for breakfast, didn't you?
You seem to divert into colorful metaphores once your arguments are smoked up. If I were to answer in the same style, I'd notice that you are still writing emails, so, no, I did not eat you ;)
On Mon, 27.10.08 15:25, seth vidal (skvidal@fedoraproject.org) wrote:
If you'd like to have a CV-off with regard to security awareness and actual experience maintaining and securing systems and networks, I'd be happy to do so.
Disabling firewalls on individual systems be they desktops or servers is a BAD idea. Full stop.
That is nonsense.
Firewalls on a desktop make no sense, and David is right is that it is a relic and not much more. It's paranoia at best to keep this installed by default.
Why are desktop firewalls wrong?
1) they are not dynamic. In times where laptops are constantly moving between networks, with stuff like zeroconf or dynamicly assigned port numbers they would need to adapt dynamically to the circumstances. However, right now they are single system-wide static rule table.
2) They do very very superficial security checking only. They hence give a false sense of security. Also, DNS or DHCP traffic is usually allowed without any inspection. Which makes the whole thing a joke. And then, using stuff like by-ip-range rules is treacherous -- IP addresses can be faked and it times von NAT not unique.
3) They are redundant -- it's just a second line of defense. If you don't trust a service you run then maybe you shouldn't be running it at all. The way we have it right now on the desktop is that the firewall is mostly just a second line of why-the-fuck-is-my-stuff-not-working.
Firewalls do make sense -- on routers and on servers -- but not so much on desktops. If you want to make them somewhat sensible on desktops then you'd have to fix issue #1 above. That means, you have to add some way that applications may issue requests to punch holes in the firewall. Which is kind of pointless, since calling listen() should implicitly be just this kind of request. And if it is, then the firewall is entirely redundant.
On routers and on servers it makes sense to use by-ip-range rules and a lot of other fancier rules. However, on the desktop -- because they move all the time between networks -- that makes no sense. So basically the desktop firewall boils down to globally allowing or globally not allowing connections to certain ports. And you know what? If that's all what a desktop fw is about, then they are completely made redundant by listen().
Also, let's note that last time I checked Ubuntu as one popular example it didn't install a firewall on the desktop. Instead they simply have a strict policy about which services may listen on a port by default. And that's exactly what we should be doing, too. On Ubuntu only very few services may listen on a port by default, one being Avahi. And those services were of course very closely checked before they were whitelisted.
That said, it would make sense to add some option to NM to mark a specific network as "not trusted -- web only" in which case mDNS and everything else would be blocked and only HTTP/DNS/DHCP would be let through. But that be optional -- and dynamic. Without that desktop firewalls are useless and everyone who wants to get work done disables them anyway. So let's disable them by default, too!
Lennart
On Mon, 2008-10-27 at 21:49 +0100, Lennart Poettering wrote:
Disabling firewalls on individual systems be they desktops or servers is a BAD idea. Full stop.
That is nonsense.
Firewalls on a desktop make no sense, and David is right is that it is a relic and not much more. It's paranoia at best to keep this installed by default.
I don't know what kind of desktops you're referring to but desktops are the soft-squishy inside that gets large corporate networks in deep trouble when there is an border fw breach. This is why it is important to have a multi-layered security policy/infrastructure. 1. border fw 2. host-based fw - including desktops 3. deny-all policies at the system level 4. well-audited apps that are runnable 5. restrictive policies on what can be run at all.
If you want to argue that enhancing the firewall technology that we are currently using to allow a more nuanced user-interaction other than 'on' or 'off' that's fine by me - but relying on selinux to solve all network-border issues seems like the wrong tool for the job.
-sv
On Mon, 27.10.08 17:04, seth vidal (skvidal@fedoraproject.org) wrote:
On Mon, 2008-10-27 at 21:49 +0100, Lennart Poettering wrote:
Disabling firewalls on individual systems be they desktops or servers is a BAD idea. Full stop.
That is nonsense.
Firewalls on a desktop make no sense, and David is right is that it is a relic and not much more. It's paranoia at best to keep this installed by default.
I don't know what kind of desktops you're referring to but desktops are the soft-squishy inside that gets large corporate networks in deep trouble when there is an border fw breach. This is why it is important to have a multi-layered security policy/infrastructure.
- border fw
- host-based fw - including desktops
- deny-all policies at the system level
- well-audited apps that are runnable
- restrictive policies on what can be run at all.
If you want to argue that enhancing the firewall technology that we are currently using to allow a more nuanced user-interaction other than 'on' or 'off' that's fine by me - but relying on selinux to solve all network-border issues seems like the wrong tool for the job.
You're missing the point. It makes no sense to split items 2-5. If a user wants to run an application then he will sit down and reconfigure all the firewalls he has control over until things work for him. (If he is not capable of that then he will file a bug and cry). And hence, having those four levels of defense is just pointless. A user will circumvent that anyway if he wants to run his app. The firewall hence simply works as an annoying extra step. It's like a message box asking you:
"Hey, you just started application 'foo'. Are you really sure you want to do that? I mean *really*?"
And if the users says "yes", then it will show another box:
"I don't believe you, but I will allow you to do it if you solve the following difficult math problem!"
Having desktop firewalls is security theatre. Having 20 levels of false and inappropriate security is worse then having a single level of security that is appropriate for the task.
Lennart
On Mon, Oct 27, 2008 at 3:19 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Mon, 27.10.08 17:04, seth vidal (skvidal@fedoraproject.org) wrote:
On Mon, 2008-10-27 at 21:49 +0100, Lennart Poettering wrote:
Disabling firewalls on individual systems be they desktops or servers is a BAD idea. Full stop.
That is nonsense.
Firewalls on a desktop make no sense, and David is right is that it is a relic and not much more. It's paranoia at best to keep this installed by default.
I don't know what kind of desktops you're referring to but desktops are the soft-squishy inside that gets large corporate networks in deep trouble when there is an border fw breach. This is why it is important to have a multi-layered security policy/infrastructure.
- border fw
- host-based fw - including desktops
- deny-all policies at the system level
- well-audited apps that are runnable
- restrictive policies on what can be run at all.
If you want to argue that enhancing the firewall technology that we are currently using to allow a more nuanced user-interaction other than 'on' or 'off' that's fine by me - but relying on selinux to solve all network-border issues seems like the wrong tool for the job.
You're missing the point. It makes no sense to split items 2-5. If a user wants to run an application then he will sit down and reconfigure all the firewalls he has control over until things work for him. (If he is not capable of that then he will file a bug and cry). And hence, having those four levels of defense is just pointless. A user will circumvent that anyway if he wants to run his app. The firewall hence simply works as an annoying extra step. It's like a message box asking you:
"Hey, you just started application 'foo'. Are you really sure you want to do that? I mean *really*?"And if the users says "yes", then it will show another box:
"I don't believe you, but I will allow you to do it if you solve the following difficult math problem!"Having desktop firewalls is security theatre. Having 20 levels of false and inappropriate security is worse then having a single level of security that is appropriate for the task.
My guess is that having priv-sep, passwords, etc are all security theatre for the desktop user in this case. I mean if application X can't work without me being root then why not be root? If having a password slows me down from getting stuff done, why not remove it. For this level.. why are we doing anything beyond Windows 98 which seems to be the perfect desktop platform.
On Mon, 27.10.08 15:29, Stephen John Smoogen (smooge@gmail.com) wrote:
Having desktop firewalls is security theatre. Having 20 levels of false and inappropriate security is worse then having a single level of security that is appropriate for the task.
My guess is that having priv-sep, passwords, etc are all security theatre for the desktop user in this case. I mean if application X can't work without me being root then why not be root? If having a password slows me down from getting stuff done, why not remove it. For this level.. why are we doing anything beyond Windows 98 which seems to be the perfect desktop platform.
You are making stupid generalizations here, and you know that.
Please don't talk to to me like I was a complete moron or something. In Avahi for example (which I wrote) I went into great lengths to run the code in an environment that is as confined as possible. We use stuff like chroot(), capabilities, we run as seperate user with minimal resource limits and stuff like that, so that even without SELinux an exploited Avahi does not allow attackers to exploit the entire system.
In fact, on my F10 system here that runs a lot of stuff in addition to the standard install, Avahi is still the *only* process which does all that security stuff. No other daemon employs chroot() or anything similar. So please, don't tell me I had no clue about how to secure daemons on Linux.
Oh, I am not sure if you every wrote anything like that. I'd be very interested to listen to you then.
Use the appropriate tools for locking things down. Don't add protection that is bogus because it will be overriden by the user anyway. I am very sure that exactly 0% of all users deactivate all the security techniques that Avahi uses -- because they have no reason to. Because it doesn't limit the use of AVahi in any way -- it doesn't go against what users want to do.
Lennart
On Mon, Oct 27, 2008 at 3:48 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Mon, 27.10.08 15:29, Stephen John Smoogen (smooge@gmail.com) wrote:
Having desktop firewalls is security theatre. Having 20 levels of false and inappropriate security is worse then having a single level of security that is appropriate for the task.
My guess is that having priv-sep, passwords, etc are all security theatre for the desktop user in this case. I mean if application X can't work without me being root then why not be root? If having a password slows me down from getting stuff done, why not remove it. For this level.. why are we doing anything beyond Windows 98 which seems to be the perfect desktop platform.
You are making stupid generalizations here, and you know that.
Lets just say we are talking past each other. I am sorry I got cranky but the people who I am used to making such arguments usually don't use firewalls, don't use any account but root and could care less about passwords. All they consider to conflict with least suprise or some such thing. When trying to design an enteprise solution where you have to argue that their Phd and 30 years of coding means I am the idiot.. I get a little testy. [It used to start that firewalls needed to be off for them, now its selinux, then firewalls, then they need to be UID 0, and then its why do I need screenlocks and passwords?] And then when it goes up the chain they go and find all the references that whatever security issue is not relevant to them which now will include the above emails that firewalls have no place on the desktop since Red Hat people say so.
So again, I am sorry I am a cranky stick-in-the-mud here.
On Tue, Oct 28, 2008 at 12:24 AM, Stephen John Smoogen smooge@gmail.com wrote:
When trying to design an enteprise solution where you have to argue that their Phd and 30 years of coding means I am the idiot.. I get a little testy.
Sorry. I build a time machine in about 10 years, then go back in time and take a job where you work just so I can annoy you. I only just found out, because my future-self just called me telling me what I'm going to do to you. Appearently all of this was done to get back at you for bumping into me, making me spill my coffee on myself at a FUDCon in like a year or two. Seems I really hold grudges.
-jef"you dont even buy me a new cup of coffee either..."spaleta
On Tue, Oct 28, 2008 at 1:20 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Tue, Oct 28, 2008 at 12:24 AM, Stephen John Smoogen smooge@gmail.com wrote:
When trying to design an enteprise solution where you have to argue that their Phd and 30 years of coding means I am the idiot.. I get a little testy.
Sorry. I build a time machine in about 10 years, then go back in time and take a job where you work just so I can annoy you. I only just found out, because my future-self just called me telling me what I'm going to do to you. Appearently all of this was done to get back at you for bumping into me, making me spill my coffee on myself at a FUDCon in like a year or two. Seems I really hold grudges.
-jef"you dont even buy me a new cup of coffee either..."spaleta
Hmmm thats must not be me. I usually give coffee away. It must have been my clone again.
On Tue, 2008-10-28 at 13:56 -0600, Stephen John Smoogen wrote:
On Tue, Oct 28, 2008 at 1:20 PM, Jeff Spaleta jspaleta@gmail.com wrote:
On Tue, Oct 28, 2008 at 12:24 AM, Stephen John Smoogen smooge@gmail.com wrote:
When trying to design an enteprise solution where you have to argue that their Phd and 30 years of coding means I am the idiot.. I get a little testy.
Sorry. I build a time machine in about 10 years, then go back in time and take a job where you work just so I can annoy you. I only just found out, because my future-self just called me telling me what I'm going to do to you. Appearently all of this was done to get back at you for bumping into me, making me spill my coffee on myself at a FUDCon in like a year or two. Seems I really hold grudges.
-jef"you dont even buy me a new cup of coffee either..."spaleta
Hmmm thats must not be me. I usually give coffee away. It must have been my clone again.
A lot can happen in a few years, apparently.
Hi all,
I've added fedora-devel-list to Cc as this topic isn't really limited to the desktop.
On Mon, 2008-10-27 at 22:48 +0100, Lennart Poettering wrote:
On Mon, 27.10.08 15:29, Stephen John Smoogen (smooge@gmail.com) wrote:
Having desktop firewalls is security theatre. Having 20 levels of false and inappropriate security is worse then having a single level of security that is appropriate for the task.
My guess is that having priv-sep, passwords, etc are all security theatre for the desktop user in this case. I mean if application X can't work without me being root then why not be root? If having a password slows me down from getting stuff done, why not remove it. For this level.. why are we doing anything beyond Windows 98 which seems to be the perfect desktop platform.
You are making stupid generalizations here, and you know that.
Please don't talk to to me like I was a complete moron or something. In Avahi for example (which I wrote) I went into great lengths to run the code in an environment that is as confined as possible. We use stuff like chroot(), capabilities, we run as seperate user with minimal resource limits and stuff like that, so that even without SELinux an exploited Avahi does not allow attackers to exploit the entire system.
In fact, on my F10 system here that runs a lot of stuff in addition to the standard install, Avahi is still the *only* process which does all that security stuff. No other daemon employs chroot() or anything similar. So please, don't tell me I had no clue about how to secure daemons on Linux.
A bit off-topic for what's really my concern with this mail, but anyway: that's probably because chroot() is seen by many as not being a security tool(*), i.e. it's giving a false sense of security that should be avoided, which would be consistent with comments made in this thread.
(*): In short: If the process can or is run as root, it can escape a chroot "jail", if it's running as a normal user, it can't really do the bad things a chroot environment would inhibit.
What I find a bit puzzling is that many people in this thread made comments about the firewall being broken (or breaking something on the desktop), but nobody thought about maybe inviting the iptables package maintainer to this discussion. I happen to know him and if one -- depending on the POV -- might accuse him of not being exactly open minded for all proposals coming out of the desktop corner, it's probably because he'd rather err on the side of caution than be sorry later.
In general I'd very much suggest, when it comes to things that affect areas other than one's own, to involve the affected persons or teams early on in the discussion. If one discusses such matters only in one's own "cabal" -- and I'm using that word with care, because that's exactly how it's come across in a few instances -- and if one only after the discussion is over presents something fait-accompli style to the rest of the world, it very much begs for being shot down. Let me compare this to casting concrete when parts of it have already begun setting, the result surely won't be stable or homogenous.
The reason for that is quite simple, it basically boils down to that nobody is super-human: We all make mistakes. To a certain degree, we tend to concentrate on the stuff we're most experienced with and miss things in other areas. Likewise, more often than not we put more priority on issues that more visibly affect our own turf than on other things and neglect how our own approach to a certain problem is detrimental in other use cases. We all occasionally can't see the wood for the trees.
Use the appropriate tools for locking things down. Don't add protection that is bogus because it will be overriden by the user anyway. I am very sure that exactly 0% of all users deactivate all the security techniques that Avahi uses -- because they have no reason to. Because it doesn't limit the use of AVahi in any way -- it doesn't go against what users want to do.
Just as a side note, you've very carefully left out people disabling avahi because it broke other things. Right on cue just this week, a colleague disabled avahi on a server where its adding a route into the 169.something auto-IP network made it unreachable in the network, maybe because that machine (for security reasons) didn't have a default gateway. The machine in question is RHEL5, so any misbehavior on part of avahi may be fixed by now, but this is still a good example for a component unintentionally breaking basic functionality because its possible impacts in "out of scope" use scenarios weren't fully assessed. Needless to say that the colleague didn't ask for avahi to be installed (it doesn't make much sense on a server), it got dragged in by dependencies.
But I'm digressing: My plea for this week would be that we'd all begin to look a bit more beyond our own noses and get to the point where involving other people and teams right away becomes the norm, instead of trying to circumvent the (perceived or not) shortcomings of components or areas for which these others are really responsible.
Nils
On Mon, 2008-10-27 at 15:29 -0600, Stephen John Smoogen wrote:
O>
I don't know what kind of desktops you're referring to but desktops are the soft-squishy inside that gets large corporate networks in deep trouble when there is an border fw breach. This is why it is important to have a multi-layered security policy/infrastructure.
- border fw
- host-based fw - including desktops
- deny-all policies at the system level
- well-audited apps that are runnable
- restrictive policies on what can be run at all.
If you want to argue that enhancing the firewall technology that we are currently using to allow a more nuanced user-interaction other than 'on' or 'off' that's fine by me - but relying on selinux to solve all network-border issues seems like the wrong tool for the job.
You're missing the point. It makes no sense to split items 2-5. If a user wants to run an application then he will sit down and reconfigure all the firewalls he has control over until things work for him. (If he is not capable of that then he will file a bug and cry). And hence, having those four levels of defense is just pointless. A user will circumvent that anyway if he wants to run his app. The firewall hence simply works as an annoying extra step. It's like a message box asking you:
"Hey, you just started application 'foo'. Are you really sure you want to do that? I mean *really*?"And if the users says "yes", then it will show another box:
"I don't believe you, but I will allow you to do it if you solve the following difficult math problem!"Having desktop firewalls is security theatre. Having 20 levels of false and inappropriate security is worse then having a single level of security that is appropriate for the task.
My guess is that having priv-sep, passwords, etc are all security theatre for the desktop user in this case. I mean if application X can't work without me being root then why not be root? If having a password slows me down from getting stuff done, why not remove it. For this level.. why are we doing anything beyond Windows 98 which seems to be the perfect desktop platform.
Stephen, Here's the problem. Yours and My experience of users is most likely very different from David's or Lennart's. Our experience is of users who need to do a finite set of tasks for work and/or education. Everything else is either disallowed by policy and/or not supported/ignored.
My experience of users is that if you give them a box and a set of rules that the overwhelming majority of them will live in that box quite fine. A handful of the folks who think of themselves as "power users" will bitch and moan and find a way to circumvent the rules. They'll complain to your boss to get you to change the rules just for them, they'll disable whatever they can. That feels a lot more like the user that Lennart and David are describing and it is NOT the users that You and I (and most of the sysadmins all over the world) actually experience. Or when we do experience them it is our penance of telling them no and then telling them no, again.
The mistake I've made is thinking that desktop==sysadmin-maintained-desktop.
What it seems like Lennart and David are describing is home and/or personal laptop/desktop. It's not for users like you and I think of. It's for people who have chosen to use linux, at home or on a machine they are exclusively in control of. A fairly narrow market from what I can see.
-sv
On Mon, Oct 27, 2008 at 4:01 PM, seth vidal skvidal@fedoraproject.org wrote:
On Mon, 2008-10-27 at 15:29 -0600, Stephen John Smoogen wrote:
O>
I don't know what kind of desktops you're referring to but desktops are the soft-squishy inside that gets large corporate networks in deep trouble when there is an border fw breach. This is why it is important to have a multi-layered security policy/infrastructure.
- border fw
- host-based fw - including desktops
- deny-all policies at the system level
- well-audited apps that are runnable
- restrictive policies on what can be run at all.
If you want to argue that enhancing the firewall technology that we are currently using to allow a more nuanced user-interaction other than 'on' or 'off' that's fine by me - but relying on selinux to solve all network-border issues seems like the wrong tool for the job.
You're missing the point. It makes no sense to split items 2-5. If a user wants to run an application then he will sit down and reconfigure all the firewalls he has control over until things work for him. (If he is not capable of that then he will file a bug and cry). And hence, having those four levels of defense is just pointless. A user will circumvent that anyway if he wants to run his app. The firewall hence simply works as an annoying extra step. It's like a message box asking you:
"Hey, you just started application 'foo'. Are you really sure you want to do that? I mean *really*?"And if the users says "yes", then it will show another box:
"I don't believe you, but I will allow you to do it if you solve the following difficult math problem!"Having desktop firewalls is security theatre. Having 20 levels of false and inappropriate security is worse then having a single level of security that is appropriate for the task.
My guess is that having priv-sep, passwords, etc are all security theatre for the desktop user in this case. I mean if application X can't work without me being root then why not be root? If having a password slows me down from getting stuff done, why not remove it. For this level.. why are we doing anything beyond Windows 98 which seems to be the perfect desktop platform.
Stephen, Here's the problem. Yours and My experience of users is most likely very different from David's or Lennart's. Our experience is of users who need to do a finite set of tasks for work and/or education. Everything else is either disallowed by policy and/or not supported/ignored.
My experience of users is that if you give them a box and a set of rules that the overwhelming majority of them will live in that box quite fine. A handful of the folks who think of themselves as "power users" will bitch and moan and find a way to circumvent the rules. They'll complain to your boss to get you to change the rules just for them, they'll disable whatever they can. That feels a lot more like the user that Lennart and David are describing and it is NOT the users that You and I (and most of the sysadmins all over the world) actually experience. Or when we do experience them it is our penance of telling them no and then telling them no, again.
The mistake I've made is thinking that desktop==sysadmin-maintained-desktop.
What it seems like Lennart and David are describing is home and/or personal laptop/desktop. It's not for users like you and I think of. It's for people who have chosen to use linux, at home or on a machine they are exclusively in control of. A fairly narrow market from what I can see.
Ah ok. I guess I have spent so much time working on making sure that people aren't sharing stuff on company owned systems... I forget that there would be a reason beyond a torrent during testing for wanting to do it otherwise.
On Mon, 2008-10-27 at 15:29 -0600, Stephen John Smoogen wrote:
My guess is that having priv-sep, passwords, etc are all security theatre for the desktop user in this case. I mean if application X can't work without me being root then why not be root? If having a password slows me down from getting stuff done, why not remove it. For this level.. why are we doing anything beyond Windows 98 which seems to be the perfect desktop platform.
Don't be silly. We want Fedora to be secure by default. Period. If your intention really is to run a DAV server at the next Blackhat conference (where e.g. it will be attacked like crazy), we can confine the used http process to only read from ~/Public. Thus, even if a malicious attacker can run code in the httpd process on your box he can only read ~/Public. He might as well not have bothered then because he could get that content via DAV.
Here's the point. A classic firewall that prevents me from sharing files via DAV doesn't really add anything if I really want to share files via DAV. If my OS vendor wants to prevent me from doing that I might as well find another OS vendor. Maybe one that actually spends energy on fixing the root problem (making services secure) instead of papering over the problem (by adding pointless firewalls).
Ironically enough Red Hat spends a lot on resources thinking about problems like these and developing technologies like SELinux (for confining processes) and D-Bus (for privilege seperation) to make our software secure. It's too bad we're not doing a good job of actually applying this in products like Fedora.
David
On Mon, 2008-10-27 at 18:01 -0400, David Zeuthen wrote:
Ironically enough Red Hat spends a lot on resources thinking about problems like these and developing technologies like SELinux (for confining processes) and D-Bus (for privilege seperation) to make our software secure. It's too bad we're not doing a good job of actually applying this in products like Fedora.
Isn't that because Fedora is all about the Upstream, and Upstreams just aren't interested in sweeping changes for adding security levels like these? (soooo not helping)
On Mon, Oct 27, 2008 at 2:49 PM, Lennart Poettering mzerqung@0pointer.de wrote:
On Mon, 27.10.08 15:25, seth vidal (skvidal@fedoraproject.org) wrote:
If you'd like to have a CV-off with regard to security awareness and actual experience maintaining and securing systems and networks, I'd be happy to do so.
Disabling firewalls on individual systems be they desktops or servers is a BAD idea. Full stop.
That is nonsense.
Firewalls on a desktop make no sense, and David is right is that it is a relic and not much more. It's paranoia at best to keep this installed by default.
Why are desktop firewalls wrong?
- they are not dynamic. In times where laptops are constantly moving
between networks, with stuff like zeroconf or dynamicly assigned port numbers they would need to adapt dynamically to the circumstances. However, right now they are single system-wide static rule table.
And for the most part that is pretty good for the desktop. Watching the traffic I see at most cafe's, the university network, etc.. firewalls are still needed and not just for Windows boxes. And to be honest the biggest set of penetration and problems that occur in the world are from desktops. Break into the desktop, and use it as your base for other desktops until you get to a server. So far this semester I have dealt with several compromised systems all were a) Linux, b) no firewall, and c) desktops or printers with embedded fedora of all things. The Windows desktops have been running behind the curve.
Why do I feel like I am reliving the 1990's desktop discussions of "why are we using this privilege seperation? it makes no sense, and keeps causing my apps to not work! Answer: Run as root. It fixes all problems."
In the end, the current firewall is a condom. It gets in the way, but for a good reason. If you can trust your partner, then do what you want.. if you can't then wear one.
2008/10/27 seth vidal skvidal@fedoraproject.org:
Just disable the firewall (service iptables stop)? That's what I do anyway. IMNSHO, these days the firewall is a relic from the 1990's era. It breaks at least mDNS (e.g. .local name resolution), gnome-user-share, banshee/rhythmbox etc. music sharing. I also think we should also disable the firewall for the desktop spin.
That's outrageously dangerous.
Please tell us why then. I also disable the firewall services since I don't have any TCP servers listening to the outside world.
Rui
On Mon, 2008-10-27 at 19:21 +0000, Rui Tiago Cação Matos wrote:
2008/10/27 seth vidal skvidal@fedoraproject.org:
Just disable the firewall (service iptables stop)? That's what I do anyway. IMNSHO, these days the firewall is a relic from the 1990's era. It breaks at least mDNS (e.g. .local name resolution), gnome-user-share, banshee/rhythmbox etc. music sharing. I also think we should also disable the firewall for the desktop spin.
That's outrageously dangerous.
Please tell us why then. I also disable the firewall services since I don't have any TCP servers listening to the outside world.
We have a number of applications that end of listening on random ports. At which point the system is vulnerable (or sometimes just the user) is vulnerable to whatever those daemons are vulnerable to.
If the firewall is on and setup to deny all, allow few then we're markedly safer for the odd port-listening daemons.
If the process needs to be able to listen on an external port then that needs to be enabled separately. You don't just turn off all the rules as a solution.
-sv
On Mon, 2008-10-27 at 15:51 -0400, seth vidal wrote:
We have a number of applications that end of listening on random ports. At which point the system is vulnerable (or sometimes just the user) is vulnerable to whatever those daemons are vulnerable to.
The solution here would be to confine these daemons with SELinux, e.g. the httpd process started by gnome-user-share would be confined to only reading from ~/Public (and writing to ~/Public/Drop Box). Of course, things like Rhythmbox would need to be split into two bits since we generally can't confine GTK+ applications.
(Also, it's funny you write "just the user". Remember that on a typical desktop system, the only high value targets are in $HOME with most of them in $HOME/.mozilla.)
If the process needs to be able to listen on an external port then that needs to be enabled separately. You don't just turn off all the rules as a solution.
However, I'd argue that people end up doing this anyway. That is, the 20% of the people that didn't give up figuring out how to do this.
David
David Zeuthen wrote:
On Mon, 2008-10-27 at 15:51 -0400, seth vidal wrote:
We have a number of applications that end of listening on random ports. At which point the system is vulnerable (or sometimes just the user) is vulnerable to whatever those daemons are vulnerable to.
The solution here would be to confine these daemons with SELinux
If the process needs to be able to listen on an external port then that needs to be enabled separately. You don't just turn off all the rules as a solution.
However, I'd argue that people end up doing this anyway.
Yes, and I suspect a large percentage of the people who are turning off the firewall because it keeps them from getting work done are also turning off SELinux because it keeps them from getting work done. So...
-- Dan
David Zeuthen wrote:
You are missing the point that the sums of the bits (our product) is larger than the bits itself (each package). I posited in my original mail that we can create a better product if we have a dictator (or group of dictators) that makes decisions. In other words, we need to move away from the model where every package maintainer maintains his own fiefdom. It's counter productive to the point that it cripples the product (e.g. the firewall example I gave earlier).
The problem is, this thing with "benevolent dictators" (I really like better Mo's "champions") is not guaranteed to work: if someone just start to act bossy, the unpaid volunteers will ignore him or go elsewhere. Sure, you may get lucky from time to time with an appointed leader (as the recent examples at the Fedora leadership, as opposed to the early years) but usually this role is earned, Linus is followed not only for his technical merits but also for his charisma (he has tons of it), a lot of people believe in him.
2008/10/27 Paul W. Frields stickster@gmail.com:
On Mon, 2008-10-27 at 12:16 +0100, Valent Turkovic wrote:
Hi, I have seen this discussed in Fedora marketing but not here or on the devel lists. On Fedora marketing list people agreed that this should be enabled: gconftool-2 --type boolean --set /apps/nautilus/preferences/always_use_browser true
Should I post this as a feature request or is it enough just to post it here in this mailing list?
If I recall correctly this was discussed to death in the GNOME upstream back when it was changed many, many moons ago. You can feel free to take this request to the upstream rather than here in Fedora.
If I were you, though, I wouldn't hold my breath about it. Many people, including myself, have become very accustomed to the spatial browser and its benefits, and would complain just as much if it were reverted.
-- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
-- Fedora-desktop-list mailing list Fedora-desktop-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-desktop-list
I guess so, that is why I wrote a simple blog post and got lots of answers (yours including), thanks. And you are right. If you can take responses to that blog post as some sort of pool it is probably 50/50.
http://snipurl.com/4qzf3 [kernelreloaded_blog385_com]
Cheers, Valent.
desktop@lists.stg.fedoraproject.org
-
Axel Thimm -
Colin Walters -
Dan Winship -
David Nielsen -
David Zeuthen -
Jef Spaleta -
Jesse Keating -
Lennart Poettering -
Max Spevack -
Máirín Duffy -
Nicu Buculei -
Nils Philippsen -
Paul W. Frields -
Ray Strode -
Rui Tiago Cação Matos -
Seth Vidal -
Stephen John Smoogen -
Valent Turkovic