1:25 p.m.
Why does Bugzilla allow filing private Fedora bugs?
I'm not sure who has the capability (it may be tied to specific
accounts). It is not all that helpful because accounts on the Cc: list
still receive notifications and can access the bug. Recipients of the
notifications may include public mailing lists. This is probably not
what people make bugs private expect.
The other problem is that I keep having to ask people filing private
bugs if it is okay with them to make them public, and then to open the
bugs again if they accidentally turn it private afterwards.
Surely it's best to remove this capability from Bugzilla?
(In case anyone wonders: We do not file Fedora bugs for embargoed
security issues at all, so a Bugzilla permissions change would have zero
impact on that front.)
Thanks,
Florian
1:42 p.m.
On 21 October 2016 at 14:25, Florian Weimer <fweimer(a)redhat.com> wrote:
Why does Bugzilla allow filing private Fedora bugs?
Because people believe they are posting private information from their
systems which they do not want to have broad dissemination. There are
many times where Fedora bugs were part of Red Hat customer information
which they wanted to keep private to the best possible.
I believe that previous conversations of getting it removed ended up
like the Debian private debates.. you can't get enough people to agree
to not wanting it or to go through the private ones to see if they can
be public.
I'm not sure who has the capability (it may be tied to specific
accounts).
It is not all that helpful because accounts on the Cc: list still receive
notifications and can access the bug. Recipients of the notifications may
include public mailing lists. This is probably not what people make bugs
private expect.
We don't run the Bugzilla so the capability of who has it and who does
not is not set by us.
The other problem is that I keep having to ask people filing private bugs if
it is okay with them to make them public, and then to open the bugs again if
they accidentally turn it private afterwards.
Surely it's best to remove this capability from Bugzilla?
(In case anyone wonders: We do not file Fedora bugs for embargoed security
issues at all, so a Bugzilla permissions change would have zero impact on
that front.)
Thanks,
Florian
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
1:49 p.m.
On Fri, Oct 21, 2016 at 2:44 PM Stephen John Smoogen <smooge(a)gmail.com>
wrote:
On 21 October 2016 at 14:25, Florian Weimer
<fweimer(a)redhat.com> wrote:
> Why does Bugzilla allow filing private Fedora bugs?
>
Because people believe they are posting private information from their
systems which they do not want to have broad dissemination. There are
many times where Fedora bugs were part of Red Hat customer information
which they wanted to keep private to the best possible.
I believe that previous conversations of getting it removed ended up
like the Debian private debates.. you can't get enough people to agree
to not wanting it or to go through the private ones to see if they can
be public.
> I'm not sure who has the capability (it may be tied to specific
accounts).
> It is not all that helpful because accounts on the Cc: list still receive
> notifications and can access the bug. Recipients of the notifications
may
> include public mailing lists. This is probably not what people make bugs
> private expect.
We don't run the Bugzilla so the capability of who has it and who does
not is not set by us.
Personally, I see this as a problem (a minor one, perhaps, but still a
problem). We should run our own, or use something which we have more
control over.
>
> The other problem is that I keep having to ask people filing private
bugs if
> it is okay with them to make them public, and then to open the bugs
again if
> they accidentally turn it private afterwards.
>
> Surely it's best to remove this capability from Bugzilla?
>
> (In case anyone wonders: We do not file Fedora bugs for embargoed
security
> issues at all, so a Bugzilla permissions change would have zero impact on
> that front.)
>
> Thanks,
> Florian
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
1:54 p.m.
On 10/21/2016 08:42 PM, Stephen John Smoogen wrote:
We don't run the Bugzilla so the capability of who has it and who
does
not is not set by us.
Bugzilla's group-based restrictions can be configured per product, so
it's easy to ask for changes if this is what we want. It doesn't even
need custom code.
Florian
12:31 a.m.
On 22/10/2016 4:54 AM, Florian Weimer wrote:
On 10/21/2016 08:42 PM, Stephen John Smoogen wrote:
> We don't run the Bugzilla so the capability of who has it and who does
> not is not set by us.
Bugzilla's group-based restrictions can be configured per product, so
it's easy to ask for changes if this is what we want. It doesn't even
need custom code.
The fedora_pm group has product ownership of the products in the Fedora
classification, this allows them to make changes like this without asking.
AFAIK the only mandatory group for community products like Fedora is the
security group, because people open bugs in the wrong place all the
time, other than that it's up to the individual communities as to which
groups can be applied to their bugs.
Cheers, Jeff.
2:08 p.m.
On 22 October 2016 at 01:31, Jeff Fearn <jfearn(a)redhat.com> wrote:
On 22/10/2016 4:54 AM, Florian Weimer wrote:
> On 10/21/2016 08:42 PM, Stephen John Smoogen wrote:
>> We don't run the Bugzilla so the capability of who has it and who does
>> not is not set by us.
>
> Bugzilla's group-based restrictions can be configured per product, so
> it's easy to ask for changes if this is what we want. It doesn't even
> need custom code.
The fedora_pm group has product ownership of the products in the Fedora
classification, this allows them to make changes like this without asking.
I was not aware of that and I thank you for the correction.
AFAIK the only mandatory group for community products like Fedora is
the
security group, because people open bugs in the wrong place all the
time, other than that it's up to the individual communities as to which
groups can be applied to their bugs.
Cheers, Jeff.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Stephen J Smoogen.
1:45 p.m.
On Fri, 2016-10-21 at 20:25 +0200, Florian Weimer wrote:
Why does Bugzilla allow filing private Fedora bugs?
I'm not sure who has the capability (it may be tied to specific
accounts). It is not all that helpful because accounts on the Cc: list
still receive notifications and can access the bug. Recipients of the
notifications may include public mailing lists. This is probably not
what people make bugs private expect.
The other problem is that I keep having to ask people filing private
bugs if it is okay with them to make them public, and then to open the
bugs again if they accidentally turn it private afterwards.
Surely it's best to remove this capability from Bugzilla?
One major reason is for abrt reports; the data abrt submits can include
sensitive stuff. abrt actually tries to detect if there is any
possibly-sensitive information in any of the stuff it uploads and makes
the bug private by default if so. This mechanism tends to be overly
sensitive, and is probably the #1 source of private Fedora bugs. But it
*is* a genuine case: we actually discovered a couple of cases back in
2013-4 of abrt-filed bugs containing users' passwords. Making those
private isn't a perfect fix - as you say, there's still a lot of people
who can access them - but it at least stops absolutely anyone from
being able to scrape them out of bugzilla (and all the search engine
bots and so on).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:56 p.m.
On 10/21/2016 08:45 PM, Adam Williamson wrote:
On Fri, 2016-10-21 at 20:25 +0200, Florian Weimer wrote:
> Why does Bugzilla allow filing private Fedora bugs?
One major reason is for abrt reports; the data abrt submits can
include
sensitive stuff.
Bugzilla is specifically not designed for keeping sensitive stuff, and
the Fedora product is certainly not set up in such a way to support
that. If we give a different impression to users, we do not care
sufficiently about our users' privacy.
Florian
2:16 p.m.
On Fri, 2016-10-21 at 20:56 +0200, Florian Weimer wrote:
Bugzilla is specifically not designed for keeping sensitive stuff
Really? Every Bugzilla that I regularly work with (GNOME, WebKit, Red
Hat) has this feature. If you have a mailing list auto-CCed to a
component, well yeah that screws it up, but otherwise it seems to work
fine?
Now, ABRT's heuristic for whether to make the bug private is really
terrible; you can imagine that any application that uses hash tables
will have "key" in the backtrace, and those all get set to private
unless the reporter decides to uncheck the box. So I never bother to
check what ABRT thinks is possibly-sensitive because it's *almost*
always wrong. Nor do I ever ask users for permission to set their bugs
public; the bug is usually never going to get fixed unless upstream can
see the backtrace, and there's almost never anything sensitive in the
backtrace. I do sanity-check the backtraces to check for obvious
sensitive data before setting them public. Nobody has complained yet.
So I think the default is bad, but the functionality really is useful
to have if used more sparingly. Occasionally people will file a WebKit
bug and ooops there's a porn URL in the command line or the backtrace,
which can be embarrassing. Sometimes users don't care, sometimes they
do, and it's good to be able to mark those as private. Adam had another
example with passwords.
Michael
4:29 p.m.
On Fri, Oct 21, 2016 at 1:16 PM, Michael Catanzaro <mcatanzaro(a)gnome.org> wrote:
On Fri, 2016-10-21 at 20:56 +0200, Florian Weimer wrote:
> Bugzilla is specifically not designed for keeping sensitive stuff
Really? Every Bugzilla that I regularly work with (GNOME, WebKit, Red
Hat) has this feature. If you have a mailing list auto-CCed to a
component, well yeah that screws it up, but otherwise it seems to work
fine?
Now, ABRT's heuristic for whether to make the bug private is really
terrible; you can imagine that any application that uses hash tables
will have "key" in the backtrace, and those all get set to private
unless the reporter decides to uncheck the box. So I never bother to
check what ABRT thinks is possibly-sensitive because it's *almost*
always wrong. Nor do I ever ask users for permission to set their bugs
public; the bug is usually never going to get fixed unless upstream can
see the backtrace, and there's almost never anything sensitive in the
backtrace. I do sanity-check the backtraces to check for obvious
sensitive data before setting them public. Nobody has complained yet.
So I think the default is bad, but the functionality really is useful
to have if used more sparingly. Occasionally people will file a WebKit
bug and ooops there's a porn URL in the command line or the backtrace,
which can be embarrassing. Sometimes users don't care, sometimes they
do, and it's good to be able to mark those as private. Adam had another
example with passwords.
Does it makes sense to have something sanitize URLs and paths that
start with /home by default? Seems like a scalpel vs backhoe is
needed.
--
Chris Murphy
5:16 p.m.
On Fri, 2016-10-21 at 15:29 -0600, Chris Murphy wrote:
Does it makes sense to have something sanitize URLs and paths that
start with /home by default? Seems like a scalpel vs backhoe is
needed.
Maybe... I dunno, sometimes the actual value really is important for
reproducing the bug. It at least does it make sense for bugs to default
to private when there's a URL or file path in the backtrace or command
line.
Michael
10:53 a.m.
On 10/21/2016 11:29 PM, Chris Murphy wrote:
On Fri, Oct 21, 2016 at 1:16 PM, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
> On Fri, 2016-10-21 at 20:56 +0200, Florian Weimer wrote:
>> Bugzilla is specifically not designed for keeping sensitive stuff
>
> Really? Every Bugzilla that I regularly work with (GNOME, WebKit, Red
> Hat) has this feature. If you have a mailing list auto-CCed to a
> component, well yeah that screws it up, but otherwise it seems to work
> fine?
>
> Now, ABRT's heuristic for whether to make the bug private is really
> terrible; you can imagine that any application that uses hash tables
> will have "key" in the backtrace, and those all get set to private
> unless the reporter decides to uncheck the box. So I never bother to
> check what ABRT thinks is possibly-sensitive because it's *almost*
> always wrong. Nor do I ever ask users for permission to set their bugs
> public; the bug is usually never going to get fixed unless upstream can
> see the backtrace, and there's almost never anything sensitive in the
> backtrace. I do sanity-check the backtraces to check for obvious
> sensitive data before setting them public. Nobody has complained yet.
>
> So I think the default is bad, but the functionality really is useful
> to have if used more sparingly. Occasionally people will file a WebKit
> bug and ooops there's a porn URL in the command line or the backtrace,
> which can be embarrassing. Sometimes users don't care, sometimes they
> do, and it's good to be able to mark those as private. Adam had another
> example with passwords.
Does it makes sense to have something sanitize URLs and paths that
start with /home by default? Seems like a scalpel vs backhoe is
needed.
Thank you for the tip.
An optional automatic data sanitization before submitting crash details to a
public bug tracker make sense to me [1]
However, the feature must be optional. Dealing with bugs opened by ABRT is
already complicated enough to discourage maintainers from reading those
reports. Hence, I cannot imagine making ABRT Bugzilla bugs less informative
by default.
Regards,
Jakub
ABRT
1: https://github.com/abrt/libreport/issues/458
11:07 a.m.
On 10/21/2016 09:16 PM, Michael Catanzaro wrote:
On Fri, 2016-10-21 at 20:56 +0200, Florian Weimer wrote:
> Bugzilla is specifically not designed for keeping sensitive stuff
Now, ABRT's heuristic for whether to make the bug private is really
terrible; you can imagine that any application that uses hash tables
will have "key" in the backtrace, and those all get set to private
unless the reporter decides to uncheck the box.
...
So I think the default is bad
I use ABRT to report crashes, I deal with ABRT reports and I'm happy with
the current default.
I am sorry. I understand your problem, but I don't have any good solution
for it.
Could you please propose a better default?
Regards,
Jakub
ABRT
11:34 a.m.
On Mon, 2016-10-24 at 18:07 +0200, Jakub Filak wrote:
I use ABRT to report crashes, I deal with ABRT reports and I'm
happy
with
the current default.
I am sorry. I understand your problem, but I don't have any good
solution
for it.
Could you please propose a better default?
The easiest solution would just be to remove "key" from the list of
sensitive phrases, I bet that would cut the false positive rate by a
huge amount.
Michael
2:24 a.m.
On 10/24/2016 06:34 PM, Michael Catanzaro wrote:
On Mon, 2016-10-24 at 18:07 +0200, Jakub Filak wrote:
> I use ABRT to report crashes, I deal with ABRT reports and I'm happy
> with
> the current default.
>
> I am sorry. I understand your problem, but I don't have any good
> solution
> for it.
>
> Could you please propose a better default?
The easiest solution would just be to remove "key" from the list of
sensitive phrases, I bet that would cut the false positive rate by a
huge amount.
OK. I'd like to see some examples of the backtrace with hash tables before I
update the list of sensitive words. Perhaps we think up a better solution.
Jakub
11:41 a.m.
On 10/21/2016 09:16 PM, Michael Catanzaro wrote:
On Fri, 2016-10-21 at 20:56 +0200, Florian Weimer wrote:
> Bugzilla is specifically not designed for keeping sensitive stuff
Really? Every Bugzilla that I regularly work with (GNOME, WebKit, Red
Hat) has this feature.
They have private bug reports, attachments, and maybe comments. But
there is no encryption (admittedly, it's difficult to do this a useful
way). A single SQL injection vulnerability likely gives you access to
everything. Same for cross-site scripting or cross-site request forgery
vulnerabilities, assuming you can get a sufficiently empowered user to
view something that triggers this. Then there is the thorny question
who gets access to private Fedora bugs. And so on.
I'm not saying that Bugzilla's features for private bits are completely
unusable. But I strongly believe that what we do today is not what
users expect when we tell them we keep private the data they submit.
Florian
6:51 p.m.
On 25/10/16 02:41, Florian Weimer wrote:
On 10/21/2016 09:16 PM, Michael Catanzaro wrote:
> On Fri, 2016-10-21 at 20:56 +0200, Florian Weimer wrote:
>> Bugzilla is specifically not designed for keeping sensitive stuff
>
> Really? Every Bugzilla that I regularly work with (GNOME, WebKit, Red
> Hat) has this feature.
They have private bug reports, attachments, and maybe comments. But there is no
encryption (admittedly,
it's difficult to do this a useful way).
Now you are just being interesting and distracting me from ... "less
interesting" pre-release work.
We would love to receive a well structured RFE from someone who has expertise in this
area.
Cheers, Jeff.
--
Jeff Fearn
Senior Software Engineer
PnT - DevOps - Development
Red Hat Asia Pacific Pty Ltd
http://dilbert.com/fast/2004-08-17/
PGP Fingerprint: B61A DC52 3E0E B17C 94D7 945C BB37 478C F119 9BCA
8:54 p.m.
Florian Weimer wrote:
Why does Bugzilla allow filing private Fedora bugs?
I am fairly sure that there used to be (in the distant past) a policy
written down somewhere that "All Fedora bugs are public". The problem is
that, after ABRT started filing those private bugs, I searched for it in all
ways possible and could not find it, nor could anybody else remember the
sentence, let alone where it was written. I suspect it must have been in
some Bugzilla help text that went away with one of Red Hat's Bugzilla
rebases.
Even without this written down anywhere, it used to be common understanding
that Fedora bugs are public by design. But then came the ABRT team. Now we
get tons of "private" bug reports. Mostly because ABRT lets users attach
tons of crazy things including core dumps (!), which of course contain
sensitive information. Many users check everything and are then surprised
that ABRT makes the stuff private by default. ABRT should really only attach
the files that actually make sense to attach. Core dumps should NEVER be
attached to a bug tracker. (It also shouldn't ask the user what to attach,
but just always attach the same sane set of files. Right now, we get some
bugs with only a backtrace, and some bugs with everything but the kitchen
sink, depending on the mood of the reporter.) Then the option to make the
report private can and should go away too.
Kevin Kofler
1:46 a.m.
On 10/25/2016 03:54 AM, Kevin Kofler wrote:
Even without this written down anywhere, it used to be common understanding
that Fedora bugs are public by design. But then came the ABRT team. Now we
get tons of "private" bug reports. Mostly because ABRT lets users attach
tons of crazy things including core dumps (!), which of course contain
sensitive information.
It is possible in theory to ask ABRT to attach a core dump file to a
Bugzilla bug but the reporter must explicitly mark the file to be attached
to the new bug.
ABRT does not automatically attach core dump files to Bugzilla bugs.
Many users check everything and are then surprised
that ABRT makes the stuff private by default.
Oops. We should improve our communication with users.
ABRT should really only attach
the files that actually make sense to attach. Core dumps should NEVER be
attached to a bug tracker.
Bugzilla itself does not prevent users from attaching core dump files - the
reporters are allowed to attach any file to a Bugzilla bug -
and ABRT does not limit the reporters too.
(It also shouldn't ask the user what to attach,
but just always attach the same sane set of files.
I believe we should allow the reporters to decide which file to attach and
which one not. We should allow it because when filling a bug manually users
allowed to choose the attachments.
We can/should update the default set of attached files to make ABRT Bugzilla
bugs less confusing.
Fedora maintainers, which files you don't want to see in Bugzilla bugs
attachments? And do you miss some information (except reproducer, this
information cannot be automatically retrieved :)?
I got an idea of squashing all the attached files into a one big text file
last month, so there would be one attachment instead of dozens. It would
make the required information harder to find in the attached file but
Bugzilla bugs would be more readable. What do you think about it?
Right now, we get some
bugs with only a backtrace, and some bugs with everything but the kitchen
sink, depending on the mood of the reporter.)
Could you please close those bugs with INSUFFICIENT_DATA?
Then the option to make the report private can and should go away
too.
Actually there are users that have the opposite opinion and that's why the
private report option exists - it wasn't the ABRT team's idea:
https://bugzilla.redhat.com/960549
https://bugzilla.redhat.com/1044653
I will repeat my argument again - users are allowed to do it when filling a
private bug manually.
Regards,
Jakub
ABRT
7:49 a.m.
There has never been any policy against private bugs, and it's been encouraged for
security sensitive bugs from day 1. There is a lot of Red Hat employees who default to
private bugs or private comments due to working mostly on internal bugs. A nice rfe might
be to enable the ability to default private comments in or off for different products.
Dennis
On 25 October 2016 7:29:25 am GMT-05:00, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
Jakub Filak wrote:
> I will repeat my argument again - users are allowed to do it when
filling
> a private bug manually.
My point is, they shouldn't be.
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
5:49 p.m.
On 25/10/16 22:49, dennis(a)ausil.us wrote:
There has never been any policy against private bugs, and it's
been encouraged for security sensitive bugs from day 1. There is a lot of Red Hat
employees who default to private bugs
FYI The warn on public create customization has been dropped from
Bugzilla 5.
or private comments due to working mostly on internal bugs. A nice
rfe might be to enable the ability to default private comments in or off for different
products.
Currently only 150 accounts have private_comment_default enabled and
only 128 of those are current, so there isn't much of a business case to
work on this feature.
Cheers, Jeff.
Dennis
On 25 October 2016 7:29:25 am GMT-05:00, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
> Jakub Filak wrote:
>> I will repeat my argument again - users are allowed to do it when
> filling
>> a private bug manually.
>
> My point is, they shouldn't be.
>
> Kevin Kofler
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
7:27 a.m.
Answers from my (user and frequent bug reporter) view:
1. abrt/libreport reports way too much data. There is no need to report my hostname to
Fedora/RedHat infrastructure. Same for UID, PID, username, time, environ, …
2. abrt/libreport leaks much sensitive data. This includes paths in my home directory, but
also other data listed above
So it is about privacy. I have reported enough bug reports containing information I
didn't want to get published so I learned to use the private flag whenever I'm not
sure I might leak information. If you want me to not use this feature any more, please
make libreport does its job at filtering private data. See
https://github.com/abrt/libreport/issues/353 for a bug report.
10:33 p.m.
Christian Stadelmann wrote:
Answers from my (user and frequent bug reporter) view:
1. abrt/libreport reports way too much data. There is no need to report my
hostname to Fedora/RedHat infrastructure. Same for UID, PID, username,
time, environ, …
The UID can actually matter. We have a frequently reported non-bug that
graphical KDE applications will not work (and abort with a qFatal, which
fires the SIGABRT signal) if you run them under tools like su or sudo
because they won't find some resources (usually the D-Bus session service,
sometimes the DISPLAY environment variable for the X display is also lost).
Even the upstream crash handler DrKonqi will then crash, because it is also
a graphical KDE application and runs in the same context, so even if KCrash
is enabled and starts DrKonqi, we still end up with an ABRT report. UID=0 is
a telltale sign that it is likely this issue again, at least it raises a red
flag. (The proper way to run KDE applications as root is to run them under
kdesu.)
Kevin Kofler
11:51 a.m.
The UID can actually matter. We have a frequently reported non-bug
that
graphical KDE applications will not work (and abort with a qFatal, which
fires the SIGABRT signal) if you run them under tools like su or sudo
because they won't find some resources (usually the D-Bus session service,
sometimes the DISPLAY environment variable for the X display is also lost).
Even the upstream crash handler DrKonqi will then crash, because it is also
a graphical KDE application and runs in the same context, so even if KCrash
is enabled and starts DrKonqi, we still end up with an ABRT report. UID=0 is
a telltale sign that it is likely this issue again, at least it raises a red
flag. (The proper way to run KDE applications as root is to run them under
kdesu.)
So actually you're not looking for the UID but whether the application ran as root.
That's enough info and I'm Ok with that.
2728
days inactive
2743
days old
24 comments
11 participants
participants (11)
-
Adam Williamson -
Chris Murphy -
Christian Stadelmann -
Christopher -
Dennis Gilmore -
Florian Weimer -
Jakub Filak -
Jeff Fearn -
Kevin Kofler -
Michael Catanzaro -
Stephen John Smoogen