I know Alex Legler is one of wiki creator. But i don't wish to log myself into the wiki. It is the only reason i could think of why he wants me to discuss a bug in the wiki. I have no reason to discuss the bug, and specially in the wiki: i report a "security bug" ; someone with a more professional attitude should look at it and say: "it is a security issue or it is not". I'm not against playing words or sarcams all he wish into bugzilla, as long as my bug stay open so another dev with a better mood can have a look at it and answer "it is a bug or not". But restricting its access to my eyes in order to force my bug stay close is not acceptable. Reproducible: Always Expected Results: "gave that bug to someone that wish to "look at the bug" instead please"
Alex is also a security team member. To the benefit of others without access to that bug, this is all about a "practice" documented in a wiki article[1]. You have a point that by copying the files you will sooner or later miss security updates for affected packages. However, I'd be more concerned with using NFS in the first place. As Alex already told you, the correct place to discuss a wiki article is in its discussion page. [1] - http://wiki.gentoo.org/wiki/Diskless_nodes#Copy_the_missing_files I'm leaving the bug open for now as I'm not trying to "silence you", but this should be CLOSED INVALID.
> Alex is also a security team member. Well, this doesn't grant anyone the title to never been wrong. > I'm leaving the bug open for now as I'm not trying to "silence you", but I couldn't access my own bug still. If you don't want make it public, at least, i should be able to handle my own bug no? This complain is about such practice that is bad (to stay polite). If nobody see a problem that Alex close it to myself (i'm not expecting having him slap nude in public place for that), but i expect the bug put back on "normal" track: open->view->close wontfix or fix it... like any bugs. (notice the open->view->close/fix steps doesn't include any discussion), i don't need to discuss the bug i've made my point in the summary already: if i wasn't thinking it is a bug, the bug report would made no sense. > You have a point that by copying the files you will sooner or later miss > security updates for affected packages. > but > this should be CLOSED INVALID. I'm a bit lost by your logic: So it's a security issue and my bug reporting a security issue is invalid? Anyway, i'm glad at least YOU did look at it ; it is what i would expect when i open the bug, even if you don't agree it is as serious as i think it is, at least you read it, understand the issue instead of sending me to some place to finally close my own bug... >As Alex already told you, the correct place to discuss a wiki article is in its discussion page. Maybe, but i'm not discussing a wiki article :D I'm reporting a bug, and the correct place is bugzilla no? You guys should really start to think about wiki: for me wiki are bad because user made (of course devs could do mistake too, but it is easier to find a user that would made a lot). So no i don't want or need to been a part of the wiki, even i agree to help pointing a part that is specially bad (in this case, a security issue). So i don't like wiki, but wiki.gentoo.org now hold the installation handbooks, to me this change its status from "a bad source of info" to "official gentoo documentation" holder. As such, any problem with "official documentation of gentoo" belong to gentoo bugzilla. Or you should clear the wiki status so: - If wiki is not offical than i will just not care about it anymore (not that i care that much, but i already suggest changes to it thru bugzilla because i care about gentoo documentation correctness a bit). But i will avoid sending any forum users to wiki. - If wiki is official, i don't see why everyone keep pointing me to discussing a bug in it must be done in the wiki. Bugzilla is the tool for bugs. And i care like many that gentoo documentation is correct, that's how i'm "trying to help" my distro ; and a security issue isn't something i myself consider weak (it is even worst as the benefits of having that security hole is giving access to some tools the server have to nodes that don't even need it). Gentoo was famous by its documentation, i don't see how you will get fame with a millions page wiki full of errors. (please note the fun part of it, that wiki article is a copy of old gentoo doc, so the bug was also present in the old doc)
(In reply to nobody from comment #2) > > Alex is also a security team member. > Well, this doesn't grant anyone the title to never been wrong. What I meant is that he is aware of security issues. BTW, with apologies to him and you, I made a mistake as he is not only a member as well one of the 2 team leads[1]. [1] - http://wiki.gentoo.org/wiki/Project:Security > > I'm leaving the bug open for now as I'm not trying to "silence you", but > I couldn't access my own bug still. If you don't want make it public, at > least, i should be able to handle my own bug no? I didn't restrict your original bug. I'll talk to Alex about that. > > You have a point that by copying the files you will sooner or later miss > > security updates for affected packages. > > > but > > this should be CLOSED INVALID. > I'm a bit lost by your logic: As I said, the correct place to discuss an issue with a Wiki article is the discussion page for that article. That's why I consider this bug should be closed as INVALID. The point is not whether there is an issue with the article or not, I agree with some of your points about it, but whether you've used the correct means to address that issue. What Alex and I have told you is that you shouldn't use bugzilla to get an issue in a Wiki article fixed. > So it's a security issue and my bug reporting a security issue is invalid? > Anyway, i'm glad at least YOU did look at it ; it is what i would expect > when i open the bug, even if you don't agree it is as serious as i think it > is, at least you read it, understand the issue instead of sending me to some > place to finally close my own bug... You are not reporting a security issue with a package in the tree or some Gentoo service. This is about a security "practice" documented in a wiki article. One that is "debatable" and in my view isn't necessarily the worst part of that document. > >As Alex already told you, the correct place to discuss a wiki article is in its discussion page. > Maybe, but i'm not discussing a wiki article :D > I'm reporting a bug, and the correct place is bugzilla no? So the next time you find an error in a forum thread you are going to open a bug about it, instead of adding a reply to the thread or mailing forums mods? > - If wiki is official, i don't see why everyone keep pointing me to > discussing a bug in it must be done in the wiki. Bugzilla is the tool for > bugs. When you find an issue with the wiki install or tools, that qualifies for a bug, but for general discussion regarding content, bugzilla is not the correct tool. After reading your comments I can see you don't like the wiki format and don't want to be "dragged into discussions" about content. Therefore, I have a suggestion for you. If you find a document with an error, you can try to reach the wiki editors or the docs team, through IRC or email and point them to it. That should allow you to provide feedback without having to deal with the wiki. Finally, even though I disagree with the bug and in part with your evaluation of the security issue with the specific wiki article, I do appreciate you taking the time to read it and to contact us about it.
(In reply to Jorge Manuel B. S. Vicetto from comment #3) > (In reply to nobody from comment #2) > I didn't restrict your original bug. I'll talk to Alex about that. Thank you, that's the point of this bug. > So the next time you find an error in a forum thread you are going to open a > bug about it, instead of adding a reply to the thread or mailing forums mods? Change gentoo forum into official gentoo documentation status and i'm afraid you will see my bug report coming ;)
(In reply to nobody from comment #2) > > Alex is also a security team member. > Well, this doesn't grant anyone the title to never been wrong. On the other hand, you should be open as well to the idea of not being right. Reopening bugs in a huff that were closed by a staff member over and over again gives me the impression you cannot accept not having the final say. > > > I'm leaving the bug open for now as I'm not trying to "silence you", but > I couldn't access my own bug still. If you don't want make it public, at > least, i should be able to handle my own bug no? > This complain is about such practice that is bad (to stay polite). If nobody > see a problem that Alex close it to myself (i'm not expecting having him > slap nude in public place for that), but i expect the bug put back on > "normal" track: open->view->close wontfix or fix it... like any bugs. > (notice the open->view->close/fix steps doesn't include any discussion), i > don't need to discuss the bug i've made my point in the summary already: if > i wasn't thinking it is a bug, the bug report would made no sense. > I have restricted your bug as you constantly kept wrongly changing the status and resolution as noted above. I'll gladly un-restrict it on the condition that you stop fiddling with it. But do note it will not be reopened, and not be assigned to anyone else, as there is no entity for 'Gentoo community' that could be an assignee. > > You have a point that by copying the files you will sooner or later miss > > security updates for affected packages. > > > but > > this should be CLOSED INVALID. > I'm a bit lost by your logic: > So it's a security issue and my bug reporting a security issue is invalid? > Anyway, i'm glad at least YOU did look at it ; it is what i would expect > when i open the bug, even if you don't agree it is as serious as i think it > is, at least you read it, understand the issue instead of sending me to some > place to finally close my own bug... Now we're confusing two issues. Issue 1, aka 'the bug': You think a paragraph in a publicly-editable part of the Wiki instructs people to commit actions that may endanger the security of their system. Issue 2: To report/fix Issue 1, you don't want to follow the canonical steps of discussing Wiki articles, and want special treatment. I deny said special treatment. This the first time I say something about issue 1, i.e. 'is this a security bug'? <hat type="security"> No, it is not a security bug. You always need to consider updating software when you install software. That goes for what you install with portage the same as for what you do with your diskless client. This is a basic principle in computing. Not noting this above such instructions does not constitute a security bug. Also, from a procedural point of view: 'Security bugs' are not a recognized term when it comes to (any kind of) documentation. As such, there are no procedures defined, and the security team is not, per its functions, responsible. </hat> Above explanation rules out the need for a 'bug' filed here which could overrule the policy for issue 2 ("no bugs about article contents"). But: <hat type="wiki"> No, it's not a security bug, but if you think it's important people remember updating that software, feel free to add a note below or above the paragraph. </hat> > > >As Alex already told you, the correct place to discuss a wiki article is in its discussion page. > Maybe, but i'm not discussing a wiki article :D > I'm reporting a bug, and the correct place is bugzilla no? You *are* discussing a wiki article. You know very well you are trying to bend semantics into your favor. Again: The canonical way of dealing with issues on articles is to (a) make the change yourself if it does not require further discussion or is otherwise minor; or (b) use the discussion page directly linked on the content page. Some pages may be restricted, but the discussion pages are always editable by anyone. > > You guys should really start to think about wiki: for me wiki are bad > because user made (of course devs could do mistake too, but it is easier to > find a user that would made a lot). So no i don't want or need to been a > part of the wiki, even i agree to help pointing a part that is specially bad > (in this case, a security issue). > So i don't like wiki, but wiki.gentoo.org now hold the installation > handbooks, to me this change its status from "a bad source of info" to > "official gentoo documentation" holder. As such, any problem with "official > documentation of gentoo" belong to gentoo bugzilla. > > Or you should clear the wiki status so: > - If wiki is not offical than i will just not care about it anymore (not > that i care that much, but i already suggest changes to it thru bugzilla > because i care about gentoo documentation correctness a bit). But i will > avoid sending any forum users to wiki. > - If wiki is official, i don't see why everyone keep pointing me to > discussing a bug in it must be done in the wiki. Bugzilla is the tool for > bugs. > And i care like many that gentoo documentation is correct, that's how i'm > "trying to help" my distro ; and a security issue isn't something i myself > consider weak (it is even worst as the benefits of having that security hole > is giving access to some tools the server have to nodes that don't even need > it). > Gentoo was famous by its documentation, i don't see how you will get fame > with a millions page wiki full of errors. (please note the fun part of it, > that wiki article is a copy of old gentoo doc, so the bug was also present > in the old doc) The Arch wiki (amongst other things) proves you wrong there on so many levels, but that's not the point of this debate. The Handbook--by your definition--is the only 'official' (i.e. restricted) documentation on the Wiki currently. The procedure for changing anything else is outlined multiple times (including above). You will not get special treatment to be allowed to file bugs for changes you can do yourself just because you don't wish to use the Wiki as an editor. And as security lead: No, security concerns do not warrant special treatment either. I hope however that you can overcome your fear of community documentation, as I don't really think it is substantiated and I know from personal experience that we have an awesome group of editors on the Gentoo Wiki that you are welcome to join.
(In reply to Alex Legler from comment #5) > (In reply to nobody from comment #2) > > > Alex is also a security team member. > > Well, this doesn't grant anyone the title to never been wrong. > > On the other hand, you should be open as well to the idea of not being Of course anyone include myself. But i will keep my bug open over and over as long as i consider someone dismissing it for no valid reason like you did. The problem is not "your reason" was valid "for you". The problem is "your reason" is only known to be valid "by you". "Each article has its own discussion page. Raise your concerns there." appears valid for you, sorry for me it doesn't as such your answer appears unapproriate handling of my issue ; i have made some security bug report and plenty ones against documentation, and i have simply never been push out to edit a wiki or any other external source from other gentoo devs. Just like your renaming of that thread, another insult for me: "the fact that Gentoo does not accept bugs for things i could change myself"... Could i change myself something in the kernel? Could i change myself openrc code? Could i change myself a documentation? Why gentoo accept any bugs when everyone could change it himself? So for me, there's no difference how documentation should be handle or not: and i'm not shock or surprise if someone tells me "i think something is wrong on the doc, but i don't want change it myself, because my ability to see a problem doesn't mean i'm a nice writer and could change it to something nice myself." Just like someone seeing a bug in the kernel doesn't mean he have the ability himself in real to code the fix. > Now we're confusing two issues. > Issue 1, aka 'the bug': You think a paragraph in a publicly-editable part of > the Wiki instructs people to commit actions that may endanger the security > of their system. > > Issue 2: To report/fix Issue 1, you don't want to follow the canonical steps > of discussing Wiki articles, and want special treatment. I deny said special > treatment. No i was in search for a treatment. Something i think you deny me. > This the first time I say something about issue 1, i.e. 'is this a security > bug'? ... Yes finally thank you ; aren't you sad we endup where we are to finally gave what i was expecting: an answer to my report? Because i am. > The Arch wiki (amongst other things) proves you wrong there on so many > levels, but that's not the point of this debate. I'm sorry, i don't know the Arch wiki myself, i'm really uninterrest by wiki generally for (bad) reason i gave earlier. So for me i would just say: "arch wiki sucks like all wiki", but i'm not arch wiki user so i don't care about its correctness or value. > I hope however that you can overcome your fear of community documentation, That's a bit of that, even i'm able to see a text is bad, i don't think as myself as stephen king, so i prefer changes been made by competent people (and i'm not even talking about language barrier, as english is not my native language as you probably notice by my faults or strange wording).
I can only invite you one last time to explore and understand the idea of editing community Wikis. If you choose to not let go of your stubborn ideas, we cannot help you.
@nobody, personally I think that the way to go would be to simply add a note to remember people to prevent that issue and be with that :/
(In reply to Pacho Ramos from comment #8) > @nobody, personally I think that the way to go would be to simply add a note > to remember people to prevent that issue and be with that :/ I have indeed suggest something like that: "It is not mention that user should really really be aware and take care anytime a server tool is update, the rsync must be redone." But i'm more surprise how a documentation exposing a security issue is not considered a security issue. It mean a gentoo doc with "chmod 777 /etc/shadow" would be fine, because: 'Security bugs' are not a recognized term when it comes to (any kind of) documentation. It is something i couldn't understand, but if everyone think that ; i can only conclude i must be wrong.
M. Ramos: thank you for the title edit.
It's not exactly about we considering it or not as a security issue. It's related with bug tracker security "component" being used for other purposes (security flaws in packages we supply in main tree generally). Bugs regarding documentation are handled in a different way -> if it's a bug in handbook and some other "central" docs you will find another component for that in our bugtracker, but for wiki pages in general you can simply edit the page yourself (if the page is not "maintained" by any concrete team... for example you can contact Gnome team if you see some issue with https://wiki.gentoo.org/wiki/Gnome/3.8-upgrade-guide for example... but it depends on each page)
