Re: [MeeGo-dev] Meego Bugs Access Denied

2011-03-31 Thread eric.le-roux
Hi,

On 3/31/11 12:05 AM, ext Andre Klapper aklap...@openismus.com 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

2011-03-31 Thread Marius Vollmer
ext eric.le-r...@nokia.com 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

2011-03-31 Thread eric.le-roux
Hi Marius,

On 3/31/11 10:07 AM, Marius Vollmer marius.voll...@nokia.com wrote:

ext eric.le-r...@nokia.com 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

2011-03-31 Thread Sivan Greenberg
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,  eric.le-r...@nokia.com wrote:
 Hi Marius,

 On 3/31/11 10:07 AM, Marius Vollmer marius.voll...@nokia.com wrote:

ext eric.le-r...@nokia.com 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

2011-03-31 Thread Clark, Joel
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

2011-03-31 Thread Ryan Ware
 -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 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

2011-03-30 Thread Sivan Greenberg
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 dne...@maemo.org 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

2011-03-30 Thread Dave Neary
Hi,

To cut this thread short:

 On Thu, Oct 28, 2010 at 6:12 PM, Dave Neary dne...@maemo.org 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

2011-03-30 Thread Andre Klapper
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

2011-03-30 Thread Gabriel M. Beddingfield


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

2011-03-30 Thread Andre Klapper
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

2011-03-29 Thread Dave Neary
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

2010-11-08 Thread Andre Klapper
[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

2010-11-02 Thread Jeremiah Foster

On Nov 1, 2010, at 20:03, Ryan Ware wrote:

 
 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. 

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

2010-11-02 Thread Carsten Munk
2010/11/2 Jeremiah Foster jeremiah.fos...@pelagicore.com:
 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

2010-11-02 Thread Jeremiah Foster

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
 jeremiah.fos...@pelagicore.com 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

2010-11-01 Thread Jeremiah Foster

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

2010-11-01 Thread Ryan Ware
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

2010-10-29 Thread Andrew Flegg
On Thu, Oct 28, 2010 at 21:08, Ryan Ware ryan.r.w...@intel.com 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

2010-10-29 Thread Igor Stoppa
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

2010-10-29 Thread Andre Klapper
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 Thread Igor Stoppa
On Fri, 2010-10-29 at 12:16 +0300, Marius Vollmer wrote:
 ext Igor Stoppa igor.sto...@nokia.com 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

2010-10-29 Thread Andre Klapper
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

2010-10-29 Thread Igor Stoppa
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

2010-10-29 Thread Auke Kok

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

2010-10-28 Thread eric.le-roux
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


Re: [MeeGo-dev] Meego Bugs Access Denied

2010-10-28 Thread Bradley Smith
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,  eric.le-r...@nokia.com 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

2010-10-28 Thread Thiago Macieira
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

2010-10-28 Thread eric.le-roux
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

2010-10-28 Thread Auke Kok

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

2010-10-28 Thread Ryan Ware
On Thu, Oct 28, 2010 at 6:18 AM, Thiago Macieira thi...@kde.org 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

2010-10-28 Thread Warren Baird
On Thu, Oct 28, 2010 at 2:17 PM, Ryan Ware ryan.r.w...@intel.com 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

2010-10-28 Thread Ryan Ware
On Thu, Oct 28, 2010 at 12:37 PM, Warren Baird
wjba...@alumni.uwaterloo.cawrote:

 On Thu, Oct 28, 2010 at 2:17 PM, Ryan Ware ryan.r.w...@intel.com 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