Re: [MeeGo-dev] Meego Bugs Access Denied
> -Original Message- > From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On > Behalf Of Marius Vollmer > Sent: Thursday, March 31, 2011 12:08 AM > To: ext eric.le-r...@nokia.com > Cc: meego-dev@meego.com > Subject: Re: [MeeGo-dev] Meego Bugs Access Denied > > "ext eric.le-r...@nokia.com" writes: > > > Indeed, file a request so we make the warning more user friendly, > > thanks. > > Can't you just do it without having a request filed? These things need to be tracked. Please file a request. Ryan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
In many cases the confidential information has been entered in a comment long after the original bug was filed as debug process progresses. -Original Message- Sivan Greenberg wrote: Can we please add mandatory fields to such bug reports: - Why is it inaccessible. - ETA for opening bug report. Such that filing those bugs will be impossible without ? -Sivan __ In many cases the confidential information has been entered in a comment long after the original bug was filed as debug process progresses. Joel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
Can we please add mandatory fields to such bug reports: - Why is it inaccessible. - ETA for opening bug report. Such that filing those bugs will be impossible without ? -Sivan On Thu, Mar 31, 2011 at 9:27 AM, wrote: > Hi Marius, > > On 3/31/11 10:07 AM, "Marius Vollmer" wrote: > >>"ext eric.le-r...@nokia.com" writes: >> >>> Indeed, file a request so we make the warning more user friendly, >>> thanks. >> >>Can't you just do it without having a request filed? > Nope. As we have a distributed team to handle bugzilla it's way easier if > we actually have a formal request... So it doesn't go into limbo if I or > someone else don't do it immediately. > Sorry for being _that_ demanding :P > > Cheers, > Eric > > ___ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
Hi Marius, On 3/31/11 10:07 AM, "Marius Vollmer" wrote: >"ext eric.le-r...@nokia.com" writes: > >> Indeed, file a request so we make the warning more user friendly, >> thanks. > >Can't you just do it without having a request filed? Nope. As we have a distributed team to handle bugzilla it's way easier if we actually have a formal request... So it doesn't go into limbo if I or someone else don't do it immediately. Sorry for being _that_ demanding :P Cheers, Eric ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
"ext eric.le-r...@nokia.com" writes: > Indeed, file a request so we make the warning more user friendly, > thanks. Can't you just do it without having a request filed? ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
Hi, On 3/31/11 12:05 AM, "ext Andre Klapper" wrote: >On Wed, 2011-03-30 at 15:56 -0500, Gabriel M. Beddingfield wrote: >> Currently, when someone happens upon a restricted bug, they >> get a scary red web page that shouts something like "Access >> Restricted! You are not authorized to view this bug." That >> page makes a person feel like they're an intruder, and are >> about to be escorted out of the building. >> >> Could this perhaps be toned down a little? Maybe add a link >> to this wiki page? +1 > >Feel free to file a request in bugs.meego.com against Bugzilla. Indeed, file a request so we make the warning more user friendly, thanks. > >andre >-- >Andre Klapper (maemo.org bugmaster) >http://www.openismus.com Cheers, Eric Le Roux MeeGo EM Lead > >___ >MeeGo-dev mailing list >MeeGo-dev@meego.com >http://lists.meego.com/listinfo/meego-dev >http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
On Wed, 2011-03-30 at 15:56 -0500, Gabriel M. Beddingfield wrote: > Currently, when someone happens upon a restricted bug, they > get a scary red web page that shouts something like "Access > Restricted! You are not authorized to view this bug." That > page makes a person feel like they're an intruder, and are > about to be escorted out of the building. > > Could this perhaps be toned down a little? Maybe add a link > to this wiki page? Feel free to file a request in bugs.meego.com against Bugzilla. andre -- Andre Klapper (maemo.org bugmaster) http://www.openismus.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
Hello, On Thu, 31 Mar 2011, Andre Klapper wrote: On Wed, 2011-03-30 at 12:45 +0200, Sivan Greenberg wrote: Customer sensitive information has one place and only one place - in customer's internal issue tracking system. [snip] FYI, we have http://wiki.meego.com/Quality/Bug_Access_Restrictions now. Cool! Currently, when someone happens upon a restricted bug, they get a scary red web page that shouts something like "Access Restricted! You are not authorized to view this bug." That page makes a person feel like they're an intruder, and are about to be escorted out of the building. Could this perhaps be toned down a little? Maybe add a link to this wiki page? Thanks, Gabriel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
On Wed, 2011-03-30 at 12:45 +0200, Sivan Greenberg wrote: > Customer sensitive information has one place and only one place - in > customer's internal issue tracking system. In theory I agree, however it requires the information provider to know what is sensitive and what isn't. As that is often impossible, in the end nearly everybody will use the internal system by default to avoid leaking sensitive info by accident. FYI, we have http://wiki.meego.com/Quality/Bug_Access_Restrictions now. andre -- Andre Klapper (maemo.org bugmaster) http://www.openismus.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
Hi, To cut this thread short: > On Thu, Oct 28, 2010 at 6:12 PM, Dave Neary wrote: ... please note the date this email was sent. I guess it was stuck in a moderation queue somewhere. Cheers, Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
As me and timeless discussed in our talk, if you state a project is open , follow the statement. If the core base as not intended to be an end user platform, and is defined as an LFS project, why does it contain CSI stuff in a linux foundation bugzilla ? I propose each "client" "customer" "vendor" whatever has his own bugzilla or issue tracking pertinent to his "derivative" to not taint the open source meego.com. Customer sensitive information has one place and only one place - in customer's internal issue tracking system. If they want something fixed (with) upstream, they should have the person (the developer, PM whatever ) affected by the bug, report it on the open source bugzilla and work there with meego.com - the upstream until it is resolved. As someone following the open source meego distro, I couldn't care less about specific customer's issues that have no relevance or origination in the open source code base in its original form, unless I'm a consultancy doing custom development services on MeeGo, for which the mentioned down applies the same. bugs.meego.com should have no "permission denied" bugs. The process for re-reporting the issue from a "customer" (onto an open source bugzilla without CSI residual) should be prompt enough and perhaps we should anchor it in a "Working with upstream MeeGo guidelines" ? I've done this with projects like RSysLog, CouchDB , CouchDBKit, Ubuntu, GNOME and many more. I think that could be a solution to this issue? Or could this create a different problem of issues not reported even thought they originate and/or affect the core pristine code base? -Sivan On Thu, Oct 28, 2010 at 6:12 PM, Dave Neary wrote: > Hi, > > eric.le-r...@nokia.com wrote: >>> Usually that reason is "security issue" or "customer sensitive >>> information". >>> >> This seems to fall under the "csi" category probably. > > The unfortunate thing for me is "this will increase in the near future > before it gets better". Is there a possibility of putting in place some > kind of process whereby the bugs can be public & sanitised (without any > CSI) and any super-zoomed surveillance photos, ballistic reports, DNA > profiles, fingerprint searches and other CSI stuff can be somewhere > else? (excuse my attempt at levity - hope it doesn't get lost in > cultural translation!) > > Having closed bugs is one thing - planning to have more is another. > >>> But like you said, there should be a way to request access for people >>> who need to know. >>> >> As far as I can tell, this situation is exceptional and we should return to >> normal very soon. >> I completely understand the frustration and actually share it... > > a suggestion would be to have a "Reason" field which would be required > when closing a bug to public - at least that way people would know why > the bug was closed off. Reasons could be "confidential information", > "Security issue" or "Oops, I checked the checkbox by mistake" :) > > Cheers, > Dave. > > -- > maemo.org docsmaster > Email: dne...@maemo.org > Jabber: bo...@jabber.org > > ___ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
Hi, eric.le-r...@nokia.com wrote: >> Usually that reason is "security issue" or "customer sensitive >> information". >> > This seems to fall under the "csi" category probably. The unfortunate thing for me is "this will increase in the near future before it gets better". Is there a possibility of putting in place some kind of process whereby the bugs can be public & sanitised (without any CSI) and any super-zoomed surveillance photos, ballistic reports, DNA profiles, fingerprint searches and other CSI stuff can be somewhere else? (excuse my attempt at levity - hope it doesn't get lost in cultural translation!) Having closed bugs is one thing - planning to have more is another. >> But like you said, there should be a way to request access for people >> who need to know. >> > As far as I can tell, this situation is exceptional and we should return to > normal very soon. > I completely understand the frustration and actually share it... a suggestion would be to have a "Reason" field which would be required when closing a bug to public - at least that way people would know why the bug was closed off. Reasons could be "confidential information", "Security issue" or "Oops, I checked the checkbox by mistake" :) Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Meego Bugs Access Denied
[Adding meego-qa@ to CC as it should handle this IMO.] Am Dienstag, den 02.11.2010, 10:59 +0100 schrieb Carsten Munk: > What I personally think should be done is simply by having a public > written policy how to deal with matters like: > > * Security sensitive bug reports > * Developers/testers/whatever contributing copyrighted information > that he has no right to, either as patches, bug report information, > etc. Such a public policy (who to set it up on the MeeGo wiki? QA team?) should also define when to completely block access to a report and when to just mark specific comments as private (so they are not visible for non-admins). Blocking access to a report might make sense when the bug summary already contains sensitive information. However the default should be to only mark specific comments as private in case they contain * copyrighted information * non-public hardware information of MeeGo stakeholders * spam advertisements for websites or non-MeeGo products * insults towards other users * (on specific request of the commenter:) content that makes the commenter appear in a bad light (commenter identity in combination with accidentially posted content like porn movie file names in .xsession-errors output etc). andre -- Andre Klapper (maemo.org bugmaster) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Nov 2, 2010, at 11:48, Jussi Kukkonen wrote: > On 11/02/2010 11:43 AM, Jeremiah Foster wrote: >> On Nov 1, 2010, at 20:03, Ryan Ware wrote: >>> >>> On Mon, Nov 1, 2010 at 10:51 AM, Jeremiah Foster >>> wrote: My understanding with most Open Source projects is that bugs would never be hidden - the current policy, even if it applies to just one hardware vendor, seems to be in direct contradiction to the Linux Foundation claims to openness. I'd like to point out that the Linux Foundation bylaws state; "The purposes of this corporation include promoting, protecting, and standardizing Linux and open source software." >>> >>> Then your understanding is incorrect. >> >> Is it? >> >> Debian is one of the oldest Linux distros, the largest in terms of >> packages, and the most successful in terms of deployment if you count >> derivatives such as Ubuntu, Mint, etc. Here's their bug policy: >> http://www.debian.org/social_contract from which I quote; "We will >> keep our entire bug report database open for public view at all >> times." >> >> Fedora is also a large, highly successful Linux Distro, here is their >> policy: http://fedoraproject.org/wiki/Security/TrackingBugs I'll >> highlight a quote: "Parent bug is publicly viewable." >> >> The GNU project which comprises a significant portion of any Linux >> distribution, including MeeGo, also has an open bug policy. >> >> Gentoo's policy has an exception that they have a security embargo: >> http://www.gentoo.org/security/en/vulnerability-policy.xml Gentoo's >> policy is reasonable because they are aiming to protect their users >> from known zero day exploits which may directly affect users. It is >> interesting to note that other Open Source projects have also >> considered this policy, but rejected it as offering no real security >> advantage. >> >> I don't think my understanding is incorrect; Open Source projects >> have open bugtrackers. > > It is incorrect, at least with regard to distros. Your statement has no basis in fact. There is not a single closed bug in Debian's BTS. Please point to a closed bug in Debian to back up your statement. > There are various ways > to deal with this and a very common approach is to keep selected bugs > closed (this is also a requirement for access to various vulnerability > information sources). If you are referring to the Vendor-sec mailing list: http://oss-security.openwall.org/wiki/mailing-lists/vendor-sec then yes that is one of the "various ways" to deal with security bugs. But this list is not "closed"; "The mailing list is unmoderated, but requests for membership are manually vetted to ensure that only the target audience may join. This is done to avoid leaking the potentially sensitive discussions, as vendor-sec members often have access to information about vulnerabilities before they become public" > As an example, these distros embargo security information in some form: > * Debian There is a security team inside Debian and the Debian Developers reference document refers to the handling of security critical bugs; http://www.debian.org/doc/developers-reference/pkgs.html#bug-security To quote from that; http://www.debian.org/doc/developers-reference/pkgs.html#bug-security If this is what you are referring to, please note this is NOT the BTS, this is the separate Security Tracker, and even here that secrecy is limited. > * Gentoo I already identified Gentoo as imposing an embargo. > * Fedora > * Ubuntu > * Mint > That's five out of the five distros you mentioned. At least four last > ones use a bug tracking system in the same way meego does. If a bug is open in Debian, it is most likely open in Ubuntu since Ubuntu is quite close to Debian, and Mint is based on Ubuntu (moving to Debian) so that point is moot too. Fedora's policy needs more scrutiny, I'm not convinced it is as you say it is, I think it is closer to Debian's policy. > Whether MeeGo bugzilla is the right place for other limited access bugs > may be debatable. Arguing that vulnerability information embargo is an > uncommon policy among distros is just silly. That is not the argument. The argument was whether or not to close bugs in the bug tracking system. I argue this is the wrong thing to do. I also concede that some form of security embargo is warranted. These two positions are not mutually exclusive. Jeremiah ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On 11/02/2010 11:43 AM, Jeremiah Foster wrote: > On Nov 1, 2010, at 20:03, Ryan Ware wrote: >> >> On Mon, Nov 1, 2010 at 10:51 AM, Jeremiah Foster >> wrote: >>> >>> My understanding with most Open Source projects is that bugs would >>> never be hidden - the current policy, even if it applies to just >>> one hardware vendor, seems to be in direct contradiction to the >>> Linux Foundation claims to openness. I'd like to point out that the >>> Linux Foundation bylaws state; "The purposes of this corporation >>> include promoting, protecting, and standardizing Linux and open >>> source software." >> >> Then your understanding is incorrect. > > Is it? > > Debian is one of the oldest Linux distros, the largest in terms of > packages, and the most successful in terms of deployment if you count > derivatives such as Ubuntu, Mint, etc. Here's their bug policy: > http://www.debian.org/social_contract from which I quote; "We will > keep our entire bug report database open for public view at all > times." > > Fedora is also a large, highly successful Linux Distro, here is their > policy: http://fedoraproject.org/wiki/Security/TrackingBugs I'll > highlight a quote: "Parent bug is publicly viewable." > > The GNU project which comprises a significant portion of any Linux > distribution, including MeeGo, also has an open bug policy. > > Gentoo's policy has an exception that they have a security embargo: > http://www.gentoo.org/security/en/vulnerability-policy.xml Gentoo's > policy is reasonable because they are aiming to protect their users > from known zero day exploits which may directly affect users. It is > interesting to note that other Open Source projects have also > considered this policy, but rejected it as offering no real security > advantage. > > I don't think my understanding is incorrect; Open Source projects > have open bugtrackers. It is incorrect, at least with regard to distros. There are various ways to deal with this and a very common approach is to keep selected bugs closed (this is also a requirement for access to various vulnerability information sources). As an example, these distros embargo security information in some form: * Debian * Gentoo * Fedora * Ubuntu * Mint That's five out of the five distros you mentioned. At least four last ones use a bug tracking system in the same way meego does. Whether MeeGo bugzilla is the right place for other limited access bugs may be debatable. Arguing that vulnerability information embargo is an uncommon policy among distros is just silly. - Jussi ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
2010/11/2 Jeremiah Foster : > I don't think anyone has a problem with a MeeGo Bugzilla security embargo as > long as that embargo is clearly explained, and reaches a consensus in the > community. My understanding was that the policy that was in place in MeeGo's > bug tracker met neither of those conditions. > Minor detail, consensus implies democracy (at least in my interpretation), while there's people responsible and a hierarchy in MeeGo - so there's someone making the last call on these issues.. Doesn't mean the discussion shouldn't happen publically, but someone has the last word and makes the final decision. The additional problem to consider is let's say, if someone posts copyrighted material to a bugtracker or any other community service. Technically a take-down notice can be sent as we're now in the project hosting copyrighted material we don't have a license to publish. Naturally we'd have to remove that material. What I personally think should be done is simply by having a public written policy how to deal with matters like: * Security sensitive bug reports * Developers/testers/whatever contributing copyrighted information that he has no right to, either as patches, bug report information, etc. We obviously can't let the project be subject to legal action so we'll need to take our precautions when matters rise.. It doesn't change the fact that a situation like this is a PITA and since we're a young project, procedures aren't written and we're learning to deal with things. These discussions hopefully lead to a better situation. BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Nov 1, 2010, at 20:03, Ryan Ware wrote: > > On Mon, Nov 1, 2010 at 10:51 AM, Jeremiah Foster > wrote: > > ...snip... > > My understanding with most Open Source projects is that bugs would never be > hidden - the current policy, even if it applies to just one hardware vendor, > seems to be in direct contradiction to the Linux Foundation claims to > openness. I'd like to point out that the Linux Foundation bylaws state; "The > purposes of this corporation include promoting, protecting, and standardizing > Linux and open source software." > > Then your understanding is incorrect. Is it? Debian is one of the oldest Linux distros, the largest in terms of packages, and the most successful in terms of deployment if you count derivatives such as Ubuntu, Mint, etc. Here's their bug policy: http://www.debian.org/social_contract from which I quote; "We will keep our entire bug report database open for public view at all times." Fedora is also a large, highly successful Linux Distro, here is their policy: http://fedoraproject.org/wiki/Security/TrackingBugs I'll highlight a quote: "Parent bug is publicly viewable." The GNU project which comprises a significant portion of any Linux distribution, including MeeGo, also has an open bug policy. Gentoo's policy has an exception that they have a security embargo: http://www.gentoo.org/security/en/vulnerability-policy.xml Gentoo's policy is reasonable because they are aiming to protect their users from known zero day exploits which may directly affect users. It is interesting to note that other Open Source projects have also considered this policy, but rejected it as offering no real security advantage. I don't think my understanding is incorrect; Open Source projects have open bugtrackers. > As I've previously explained the vast majority (if not all) highly visible > open source projects keep security issues closed until they are resolved. I don't think anyone has a problem with a MeeGo Bugzilla security embargo as long as that embargo is clearly explained, and reaches a consensus in the community. My understanding was that the policy that was in place in MeeGo's bug tracker met neither of those conditions. Jeremiah > > That said, there is no reason I see that this particular bug should have been > anything but open. > > Ryan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Mon, Nov 1, 2010 at 10:51 AM, Jeremiah Foster < jeremiah.fos...@pelagicore.com> wrote: > > ...snip... > > My understanding with most Open Source projects is that bugs would never be > hidden - the current policy, even if it applies to just one hardware vendor, > seems to be in direct contradiction to the Linux Foundation claims to > openness. I'd like to point out that the Linux Foundation bylaws state; > "The purposes of this corporation include promoting, protecting, and > standardizing Linux and open source software." > Then your understanding is incorrect. As I've previously explained the vast majority (if not all) highly visible open source projects keep security issues closed until they are resolved. That said, there is no reason I see that this particular bug should have been anything but open. Ryan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Oct 29, 2010, at 22:45, Auke Kok wrote: > On 10/29/10 02:28, Igor Stoppa wrote: >> Hi, >> On Fri, 2010-10-29 at 09:22 +0100, ext Andrew Flegg wrote: >>> The lack of information can lead to the >>> frustration in this thread - especially if there are still mistakes >>> slipping through (such as #8474). >> >> Let's try to clarify some aspect that seems to be going under the radar. >> Here we are dealing also with 3rd party IPs, including - mostly - HW/FW. There is no place for third party non-OSI approved software or firmware in an Open Source bugtracker. Please see bug 9525 which blocks the MeeGo Meta Openness bug 4898 (http://bugs.meego.com/show_bug.cgi?id=9525) Having third party firmware of software opens MeeGo up to patent litigation. >> While the goal is obviously to be as open as possible, it's a fact hat >> some _HW_ companies might get - rightfully - touchy if their data is >> published in an uncontrolled way. This seems incompatible with Open Source development. I don't think this is in fact a reasonable request and I don't think it should be honored. Intel and other companies are being very open with the MeeGo software and hardware, it seems completely unfair that bugs can't get fixed due to hardware vendor's unreasonable demands. Filing bugs is clearly within a user's rights, after all, it is their hardware and they should be allowed to get it to work and a bug report is a fundamental part of this. Furthermore, I am certain that at least some of the closed bugs in Bugzilla are also filed in other places, so you are not closing the bugs or the issues with the buggy firmware, you are only closing off the opportunity for someone to fix the issue for you in MeeGo. You will now be dependent on other software projects, like Debian (who never close bugs) because people will actually be able to see the bugs in Debian's system and fix them there instead of in MeeGo. >> >> There are processes in place to ensure that data is published in a >> controlled way, but they take time. Is this policy part of an official Linux Foundation document? My understanding with most Open Source projects is that bugs would never be hidden - the current policy, even if it applies to just one hardware vendor, seems to be in direct contradiction to the Linux Foundation claims to openness. I'd like to point out that the Linux Foundation bylaws state; "The purposes of this corporation include promoting, protecting, and standardizing Linux and open source software." >> >> #8474 was a mistake in the sense that it should have not gone public at >> all - at least not now. And the following glitch closed-public-closed >> was another thing that could have been avoided. > > this is a rather misrepresentation of the problem. > > bug #8474 is in fact titled: > > === > Bug 8474 - [1.2] "org.oFono" service can not be found on Dbus with > voicecallhistory issue > === > > There is nothing about this bug that should have been private to begin with. > The real issue is that information was entered into this bug report that was > irrelevant that forced me to reclose the bug (although I still highly object > to this bug being closed). > > here is the original core content of bug 8474: > > === > 1.Boot image to home screen. Check the default configuration of > /etc/ofonod/modem.conf [phonesim] section is commented. > 2.Launch dialer, the dialog "Fail to connect to org.ofonod.Manager: is ofonod > running?" pops up while ofonod process is running. > 3.Uncomment the [phonesim] section and make sure address is 127.0.0.1. > 4.Dialer is uable to launcher from quick launch bar. > === > > nothing in here that can't be disclosed and doesn't accurately describe the > bug to begin with. > > This bug should have been filed properly without referencing content that > couldn't be disclosed, then the whole discussion would have never happened. > > Auke > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On 10/29/10 02:28, Igor Stoppa wrote: Hi, On Fri, 2010-10-29 at 09:22 +0100, ext Andrew Flegg wrote: The lack of information can lead to the frustration in this thread - especially if there are still mistakes slipping through (such as #8474). Let's try to clarify some aspect that seems to be going under the radar. Here we are dealing also with 3rd party IPs, including - mostly - HW/FW. While the goal is obviously to be as open as possible, it's a fact hat some _HW_ companies might get - rightfully - touchy if their data is published in an uncontrolled way. There are processes in place to ensure that data is published in a controlled way, but they take time. #8474 was a mistake in the sense that it should have not gone public at all - at least not now. And the following glitch closed-public-closed was another thing that could have been avoided. this is a rather misrepresentation of the problem. bug #8474 is in fact titled: === Bug 8474 - [1.2] "org.oFono" service can not be found on Dbus with voicecallhistory issue === There is nothing about this bug that should have been private to begin with. The real issue is that information was entered into this bug report that was irrelevant that forced me to reclose the bug (although I still highly object to this bug being closed). here is the original core content of bug 8474: === 1.Boot image to home screen. Check the default configuration of /etc/ofonod/modem.conf [phonesim] section is commented. 2.Launch dialer, the dialog "Fail to connect to org.ofonod.Manager: is ofonod running?" pops up while ofonod process is running. 3.Uncomment the [phonesim] section and make sure address is 127.0.0.1. 4.Dialer is uable to launcher from quick launch bar. === nothing in here that can't be disclosed and doesn't accurately describe the bug to begin with. This bug should have been filed properly without referencing content that couldn't be disclosed, then the whole discussion would have never happened. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Fri, 2010-10-29 at 11:45 +0200, ext Andre Klapper wrote: > Am Freitag, den 29.10.2010, 13:11 +0300 schrieb Igor Stoppa: > > AFAIK it's not possible to partially censor a bug and hide only some > > comments. > > It is possible. > For admins there is a "Private" checkbox next to every comment that > enables only "insidergroup" members (defined in the Bugzilla group > security configuration) to view the comment. Oh! thanks for the explanation Well, then i guess it's a matter of going over these bugs and filtering them ... I see no problem as long as it's done by someone with enough security clearance to read them and competence to understand them. cheers, igor ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
Am Freitag, den 29.10.2010, 13:11 +0300 schrieb Igor Stoppa: > AFAIK it's not possible to partially censor a bug and hide only some > comments. It is possible. For admins there is a "Private" checkbox next to every comment that enables only "insidergroup" members (defined in the Bugzilla group security configuration) to view the comment. andre -- Andre Klapper (maemo.org bugmaster) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Fri, 2010-10-29 at 12:16 +0300, Marius Vollmer wrote: > ext Igor Stoppa writes: > > > Said this, I think it must be accepted that we are not very close yet to > > the point where also HW design and FW source code are open, so it will > > be inevitable that some bugs will be tracked all the way down to the > > lower levels and then the visibility will stop. > > But that doesn't mean that the whole history of the bug so far has to be > hidden. Simply saying that the issue is now tracked somewhere else and > that you will come back with the result should be enough. If things go well, yes, you are correct. In the specific case things didn't go well and it was too late. AFAIK it's not possible to partially censor a bug and hide only some comments. cheers, igor ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Fri, 2010-10-29 at 11:19 +0200, ext Carsten Munk wrote: > 2010/10/29 Igor Stoppa : > As such, there's really not much issue about hiding some things, but > we need procedures to handle these kind of situations, publically > described - people are much much more inclined to accept things if > they're documented. yup, i blame this mostly on the fact that we all are getting used to a new way of doing things. > We can have a win-win situation by having more community in the > bugzilla, so people feel free to discuss the entire platform from top > to bottom. > > 8474 is a nightmare because currently, as stated in > http://wiki.meego.com/Quality/HandsetTestReport/1.2_N900Acceptance20101028 > , [1.2] "org.oFono" service can not be found on Dbus, which causes > modem power on fail. This blocks N900 images naturally and probably > also others. > > This could be handled much better since there's obviously a deeper > issue beyond 'modem power on fail' and -that- bug could be forked and > made 'secret'. I believe that specific one should be reworked and forked, possibly as proposed below. What we have seen was an emergency situation where the emergency brake was pulled and it's not meant to be nice, it's meant to be mostly effective. > So, I propose the following procedure: > Just don't get things to a point where we require a NDA to help admin > the bugzilla. Think that in the future, Linux Foundation, Intel, > Nokia, Acer and many others has to work together to make that central > piece of -community infrastructure- work properly. So maybe we should > instead help in MeeGo with central functions to say "export/move this > bug to bugzilla instance http://bugzilla.momcorp.com"; where private > talks can go on. And the same from the products bugzilla's vendors > build, think Nokia MeeGo exporting a bug to MeeGo.com. :-) I'm not the one to be convinced, but it's a fact that legal agreements are binding and must be respected. Things can be changed, but playing by the rules. Starting from existing setups usually helps. For example this: http://www.kroah.com/log/linux/free_drivers.html could also be extended to bugs-handling. cheers, igor ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
Am Freitag, den 29.10.2010, 12:16 +0300 schrieb Marius Vollmer: > I think we have traditionally been worried about someone _filing_ a bug > in a public place that he has found on secret hardware. > > For example, Nokia might pay someone to test MeeGo software on an > upcoming super secret phone model, and the tester then files the bug > he/she finds, dutifully identifying the exact hardware device has has > used. which gived away the existence of that device, it's code name, > some hints about a schedule, maybe some hardware features, etc. The danger can be decreased by teaching people how to identify secret information & good behavior but of course that takes time and efforts. (And in general it is possible for Bugzilla admins to only set a specific comment in a report to "Private" instead of the complete report.) andre -- Andre Klapper (maemo.org bugmaster) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
2010/10/29 Igor Stoppa : > While the goal is obviously to be as open as possible, it's a fact hat > some _HW_ companies might get - rightfully - touchy if their data is > published in an uncontrolled way. > > > #8474 was a mistake in the sense that it should have not gone public at > all - at least not now. And the following glitch closed-public-closed > was another thing that could have been avoided. > > This is not peculiar to MeeGo and affects also other open projects (see > kernel vs ACPI bios) where eventually bug tracking hits the wall of non > public IPs and the. > > The only difference is that here we are addressing end-to-end use cases > with all the bugs kept in one single repository and therefore some > access control must be exerted. As such, there's really not much issue about hiding some things, but we need procedures to handle these kind of situations, publically described - people are much much more inclined to accept things if they're documented. We can have a win-win situation by having more community in the bugzilla, so people feel free to discuss the entire platform from top to bottom. 8474 is a nightmare because currently, as stated in http://wiki.meego.com/Quality/HandsetTestReport/1.2_N900Acceptance20101028 , [1.2] "org.oFono" service can not be found on Dbus, which causes modem power on fail. This blocks N900 images naturally and probably also others. This could be handled much better since there's obviously a deeper issue beyond 'modem power on fail' and -that- bug could be forked and made 'secret'. So, I propose the following procedure: * A field, "Private conversation wished", with Proposed/Approved/Rejected like in the 1.1 release blocker system When the vendor confidentiality/private conversation is granted, QA contacts proposer, creates a bug with the participants wished in the conversation in CC, marks it secret with only access to those in CC (or later added). The bug is marked as a blocker for the original bug and when people access it, it is marked as that private conversation has been requested. The participants are performing their conversation in that bug. This system can also be used in case of reporting bugs with private information. Think browser crash with pornography in the current tab. Just don't get things to a point where we require a NDA to help admin the bugzilla. Think that in the future, Linux Foundation, Intel, Nokia, Acer and many others has to work together to make that central piece of -community infrastructure- work properly. So maybe we should instead help in MeeGo with central functions to say "export/move this bug to bugzilla instance http://bugzilla.momcorp.com"; where private talks can go on. And the same from the products bugzilla's vendors build, think Nokia MeeGo exporting a bug to MeeGo.com. Best regards, Carsten Munk MeeGo Nokia N900 hardware adaptation maintainer ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
ext Igor Stoppa writes: > Said this, I think it must be accepted that we are not very close yet to > the point where also HW design and FW source code are open, so it will > be inevitable that some bugs will be tracked all the way down to the > lower levels and then the visibility will stop. But that doesn't mean that the whole history of the bug so far has to be hidden. Simply saying that the issue is now tracked somewhere else and that you will come back with the result should be enough. I think we have traditionally been worried about someone _filing_ a bug in a public place that he has found on secret hardware. For example, Nokia might pay someone to test MeeGo software on an upcoming super secret phone model, and the tester then files the bug he/she finds, dutifully identifying the exact hardware device has has used. which gived away the existence of that device, it's code name, some hints about a schedule, maybe some hardware features, etc. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
Hi, On Fri, 2010-10-29 at 09:22 +0100, ext Andrew Flegg wrote: > The lack of information can lead to the > frustration in this thread - especially if there are still mistakes > slipping through (such as #8474). Let's try to clarify some aspect that seems to be going under the radar. Here we are dealing also with 3rd party IPs, including - mostly - HW/FW. While the goal is obviously to be as open as possible, it's a fact hat some _HW_ companies might get - rightfully - touchy if their data is published in an uncontrolled way. There are processes in place to ensure that data is published in a controlled way, but they take time. #8474 was a mistake in the sense that it should have not gone public at all - at least not now. And the following glitch closed-public-closed was another thing that could have been avoided. Said this, I think it must be accepted that we are not very close yet to the point where also HW design and FW source code are open, so it will be inevitable that some bugs will be tracked all the way down to the lower levels and then the visibility will stop. This is not peculiar to MeeGo and affects also other open projects (see kernel vs ACPI bios) where eventually bug tracking hits the wall of non public IPs and the. The only difference is that here we are addressing end-to-end use cases with all the bugs kept in one single repository and therefore some access control must be exerted. cheers, igor ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Thu, Oct 28, 2010 at 21:08, Ryan Ware wrote: > > Thanks for the understanding on security issues. I know that this > discussion wasn't really kicked off because of a bug with security concerns, > but I wanted to put my position on that out to the community because it was > subsequently brought up. Agreed. I wonder if there's something that can be done with Bugzilla where security bugs are hidden but the user is told *why* it is hidden. "You are not authorised to see this bug as it concerns an in-progress security issue" is more useful than "You are not authorised to see this bug [because someone may have gone back to old default closed processes]". The lack of information can lead to the frustration in this thread - especially if there are still mistakes slipping through (such as #8474). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Thu, Oct 28, 2010 at 12:37 PM, Warren Baird wrote: > On Thu, Oct 28, 2010 at 2:17 PM, Ryan Ware wrote: > > > > > > There are a number of bugs in the MeeGo Bugzilla that are restricted > > specifically to the security group. > > I suspect everyone understands the need to limit access to security > bugs - I certainly do. However, the OP and the immediate follow up > made no mention of security issues... > > If the only issues with restricted access are security issues, that's > great - but Eric's follow seems to imply that there are non-security > bugs that will be restricted, and that we can expect more until some > non-described problem is sorted out... > > If some bugs are being restricted without a good reason - I'd agree > with Bradley that it's a pretty serious issue. > > > Thanks for the understanding on security issues. I know that this discussion wasn't really kicked off because of a bug with security concerns, but I wanted to put my position on that out to the community because it was subsequently brought up. I also agree that if there is not a good reason that is broadly accepted by the community as to why a bug or class of bugs is closed to the community, there is a significant issue that needs to be addressed. Ryan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Thu, Oct 28, 2010 at 2:17 PM, Ryan Ware wrote: > > > There are a number of bugs in the MeeGo Bugzilla that are restricted > specifically to the security group. I suspect everyone understands the need to limit access to security bugs - I certainly do. However, the OP and the immediate follow up made no mention of security issues... If the only issues with restricted access are security issues, that's great - but Eric's follow seems to imply that there are non-security bugs that will be restricted, and that we can expect more until some non-described problem is sorted out... If some bugs are being restricted without a good reason - I'd agree with Bradley that it's a pretty serious issue. Warren -- Warren Baird - Photographer and Digital Artist http://www.synergisticimages.ca ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Thu, Oct 28, 2010 at 6:18 AM, Thiago Macieira wrote: > On Thursday, 28 de October de 2010 05:44:09 Bradley Smith wrote: > > You need to be presenting a darn good reason why bugs are not being > > shown to everyone. > > Usually that reason is "security issue" or "customer sensitive > information". > > But like you said, there should be a way to request access for people who > need > to know. > > There are a number of bugs in the MeeGo Bugzilla that are restricted specifically to the security group. They remain closed to only the security group, the bug submitter and the cc list until a fix for the security issue is available. Once a fix is available, the bug is made public. The reason for this is that until a fix is in place, the bug is essentially a map on how to exploit a MeeGo system. We also have commitments to keep certain bugs embargoed until a fix is available for the majority of Linux distributions. While I strongly appreciate the need for access of information in an open project like this (and I try to error on the side of the community), this is also best practices as followed by all the leading Linux distributions. If anyone here feels that they need access to a specific security related bug, please send me an email and I will evaluate and see what we can do. Thanks, Ryan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On 10/28/10 02:28, Gary Birkett wrote: Hey, I have encountered a number of bugs this morning as part of my work on the meego bug tracker which are giving an error: "You are not authorized to access bug #[bugid]" (related to something I expected to read and digest) This issue effects people in other areas too A specific example this morning was stskeeps could not access http://bugs.meego.com/show_bug.cgi?id=8474 I just removed this restriction on this bug, there's no reason why it ever should have been restricted to begin with. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
Hi, >-Original Message- >From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] >On Behalf Of ext Thiago Macieira >Sent: 28 October, 2010 16:18 >To: meego-dev@meego.com >Subject: Re: [MeeGo-dev] Meego Bugs Access Denied > >On Thursday, 28 de October de 2010 05:44:09 Bradley Smith wrote: >> You need to be presenting a darn good reason why bugs are not being >> shown to everyone. > >Usually that reason is "security issue" or "customer sensitive >information". > This seems to fall under the "csi" category probably. >But like you said, there should be a way to request access for people >who need to know. > As far as I can tell, this situation is exceptional and we should return to normal very soon. I completely understand the frustration and actually share it... >-- >Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Senior Product Manager - Nokia, Qt Development Frameworks > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 Cheers, Eric Le Roux MeeGo error management lead ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
On Thursday, 28 de October de 2010 05:44:09 Bradley Smith wrote: > You need to be presenting a darn good reason why bugs are not being > shown to everyone. Usually that reason is "security issue" or "customer sensitive information". But like you said, there should be a way to request access for people who need to know. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Senior Product Manager - Nokia, Qt Development Frameworks PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
I don't want to be rude here, but I feel that I need to interject. (So no rudeness or just shooting messengers intended) On Thu, Oct 28, 2010 at 8:31 PM, wrote: > We are working on making these defects visible again as soon as possible. > There's a chance that the number still grows in the coming days yet the > situation should come back to normal quite soon. No, just no. This is an open project. You cannot just say that you will open them up (basically) when you feel like doing it and then furthermore say that more bugs will happen like this - closed off from the open. You need to be presenting a darn good reason why bugs are not being shown to everyone. This is not Nokia where things are closed first, opened on a case-by-case basis. This is an open project, where things should be open unless there are extreme circumstances and reasoning that would allow that bug to be closed (eg. major security bug). Even if there are closed off bugs, there should be a process in order to be able to view these bugs. People are trying to do the best job they can within the MeeGo project, without them getting access to these bugs, they will get blamed for it being missed out on - but they can't even view it! It is hindering their progress. Now you mention that more unexplained closed off bugs will come. Unacceptable. Seriously, sometimes I need to slap myself across the face a couple of times to remember whether this is an open project or a marketing scheme with Nokia and Intel puppeteers. But then I remember it is an open project, with a lot of people acting in the manner they should but it seems like not everyone has crossed the bridge yet to realizing and remembering to participate in the open. > BR, > Eric Cheers, Bradley Smith IRC: Termana ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Bugs Access Denied
Hi Gary, We are working on making these defects visible again as soon as possible. There's a chance that the number still grows in the coming days yet the situation should come back to normal quite soon. Sorry for the inconvenience! BR, Eric >-Original Message- >From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] >On Behalf Of ext Gary Birkett >Sent: 28 October, 2010 12:29 >To: Development for the MeeGo Project >Subject: [MeeGo-dev] Meego Bugs Access Denied > >Hey, > >I have encountered a number of bugs this morning as part of my work on >the meego bug tracker which are giving an error: >"You are not authorized to access bug #[bugid]" >(related to something I expected to read and digest) > >This issue effects people in other areas too > >A specific example this morning was stskeeps could not access >http://bugs.meego.com/show_bug.cgi?id=8474 > >this bug is highlighted multiple times in the acceptance report >http://wiki.meego.com/Quality/HandsetTestReport/1.2_N900Acceptance201010 >28 > >Is there a general documented mechanism to follow to get access to >these bugs or to generally unlock them? >(going through team leaders based on requirements is normal) > >Gary >___ >MeeGo-dev mailing list >MeeGo-dev@meego.com >http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Meego Bugs Access Denied
Hey, I have encountered a number of bugs this morning as part of my work on the meego bug tracker which are giving an error: "You are not authorized to access bug #[bugid]" (related to something I expected to read and digest) This issue effects people in other areas too A specific example this morning was stskeeps could not access http://bugs.meego.com/show_bug.cgi?id=8474 this bug is highlighted multiple times in the acceptance report http://wiki.meego.com/Quality/HandsetTestReport/1.2_N900Acceptance20101028 Is there a general documented mechanism to follow to get access to these bugs or to generally unlock them? (going through team leaders based on requirements is normal) Gary ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev