Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 27 Jan 2018 12:03:25 +0000
From: halfdog <me@...fdog.net>
To: oss-security@...ts.openwall.com
Subject: Re: How to deal with reporters who don't want their bugs fixed?

Mikhail Utin wrote:
> I 100% agree with Solar's response. We should not limit our
> freedom to choose how we will handle our intellectual property.

We should not limit our "effective freedom", that is limit the
number of options we could direct our results or activities. As
reality is a strange thing, our "effective freedom" in the long
run can be reduced greatly by using "real freedom" at the beginning.

OS example: take your "real freedom" to strace SUID-binaries and
you lose the "effective freedom", what you could do with that
binary if it would have kept its SUID properties.

Disclosure example: If you take your "real freedom" to publish
as you want, you will limit the "effective freedom" to evolve
your ideas in a cooperative, stimulating environment, getting
information earlier or unfiltered, get your results and solutions
into the community faster and at a higher quality, ...



Therefore rules describing how we limit or extend our own freedom
seem to make sense to me. As pointed out, writing them under the
term "ethics" might not be the right approach as it requires some
wider concept of good and bad. But from my point of view, something
else might make sense: defining a "code of conduct"

This code does not attempt to make a distinction if something
is universially good or bad, it just declares how things are.
I have the impression, that defining such codes in a somehow
standardised way (boilerplate approach) for both sides, reporters
and projects/vendors, may ease the collaboration and thus give
both parties more "effective freedom".

I took my "real freedom" to disgrace myself and attached an attempt
to write a personal "code of conduct", see below. As there is
no applicable international legal framework or en gros accepted
certifications or standards, that is suitable to build trust in
the person or organization behind such plain-text CoC-documents,
trust should be generated by the community.

Maybe heavyweight reputation management might be an overkill,
but some involved parties may want a technical scheme to manage
trust. Maybe something like signing code of conducts of other
parties could be used for that, although I did not really develop
that idea further, how that could be done technically. I usually
assume, that standardizing a procedure is the real work, the tools
to assist it are easy to find or create, as soon as a majority
of parties are commited to move in the same direction. See the
last paragraph of the attachment, for some kind of proposal.

> That is how I read the original statements below.
>
> Not to cause more discussion, but here is the example of how
> "universal ethics" work:
>
> https://www.theregister.co.uk/2018/01/25/intel_spectre_disclosed_flaws_november/

Spectre is a nice example, also from another perspective. Did someone
compare e.g. the current wiki pages on Spectre/Meltdown with e.g.
https://usn.ubuntu.com/usn/usn-3522-1/ ?

Of course there are notorious "IT-security professionals", who
just want to spread destruction in their name. But there are also
ones, that just want to make a decent living from their skils or
in research areas, want to be seen at some level to earn research
grants (yes, universities have to get their funding also on the
free market), keep their position at universities (publish or
parish), ...

Question: someone knowing both documents, what (correct or incorrect)
conclusions he might draw and how would he adapt his disclosure
strategy in future?

In my opinion, without having a minimalistic underlying framework
to build and leverage trust, irrational and risky behaviour might
become the more effective strategy, not only for egoistic individuals
but also those who want to play nice but have the feeling that
they are losing grounds compared to the big ones. Hence this is
also about managing "attribution" in a consistent way, as without
other standards, you are only judged by your deeds (and what is
known about them).

hd

> ________________________________ From: Solar Designer
> <solar@...nwall.com> Sent: Friday, January 26, 2018 12:16 To:
> oss-security@...ts.openwall.com Subject: Re: [oss-security]
> How to deal with reporters who don't want their bugs fixed?
>
> On Fri, Jan 26, 2018 at 10:23:49AM -0500, Stiepan wrote:
>> I think that clear rules might be welcome:
>
> I agree (specifically, I had suggested explicit maximum embargo
> times), but such rules must not be one and only industry standard.
>  Anyone or any project may propose rules, and other projects
> are welcome to reuse those rules, but they must not have to
> - they could as well use different rules, or none.  At best,
> a relatively non-controversial and brief boilerplate could
> end up being reused by many projects.
>
>> We as a profession should have a clear code of ethics
>
> No.  Let's not use the word ethics.  That word, except when
> explicitly referring to a particular person's or group's ethics,
> implies that when we (dis)agree or are judging others, we claim
> to be necessarily right - but in reality we're necessarily
> subjective.
>
> This would be just as flawed a concept/term as "responsible
> disclosure". (I refrain from using that term as well, except
> when pointing out just how unnecessarily judgemental it is
> - implying that other kinds of disclosure would have been
> "irresponsible" - but we're subjective.)
>
>> universal ethics' code
>
> That's an oxymoron.  No such thing can possibly exist.
>
> Alexander

View attachment "SecurityResearcher-CodeOfConduct-LeisureResearcher.txt" of type "text/plain" (1821 bytes)

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.