Wow. I had not expected that quick of a reaction with such a long email :)

> Call me a pessimist but I highly doubt your commercial users are going to
> be willing to shoulder any cost associated with auditing the software, nor
> do I think it would be looked upon favorably by most to even suggest it.
>
>
I am right now discussing this very issue with one of our commercial users
(the one from issue 2) and I think I managed to at least (by being a little
assertive or even a bit pushy to be honest - that was a bit of an
experiment) to spark a conversation about that. The user  (turns out -
consulting project with a "big commercial entity") who wanted to answer,
now at least routed our "we are not sure but here is the issue and you can
help by contributing" to the product manager of the "big commercial entity".

I understand being pessimist or optimist here matters. But I personally
think it does not matter what the situation is now, it's more about how we
shape the future. I believe by our actions, transparent communication of
our expectations and involving "big users" and "3rd-parties" - for example
Lars's company - we can absolutely influence how the future of those
relations will look like. Nobody (except regulations) can FORCE us to give
authoritative answers for 3rd-party libraries. And we always have the
option to answer not "yes" or "no" but "maybe, but you can help to move the
needle in the yes/no direction if you need it". This is IMHO what the whole
Open-Source business should be doing right now before the regulations are
in effect - start educating the commercial users of ours that "knowing if
you are vulnerable from 3rd-parties" is not part of the "free lunch" of the
OSS. They got used to getting everything for free  in OSS, but in fact we
(and even the OSS as a movement) NEVER promised everything around the
software will be free. The software itself is free, but are services around
that free ? Not at all. Companies pay a lot of money for "managed version
of XXX". Why should not they pay for "security certainty for all the
3rd-party components". We have not promised that. It's not part of the deal
or the licence they have from us. I don't think we should pay for it, they
should.

Generally security is not a 0/1 business - it's always about taking
calculated risk (you can never protect 100% - there is always uncertainty
and risk that you overlooked something). The big question here is what risk
it is and whose responsibility it is  to take  the risk. Having
authoritative answers from the ASF / PMC means that we are taking the risk.
Or we pay the cost (and we have basically no money to do so - just
volunteers) for decreasing the risk by making deeper analysis. So my quest
is really how to turn it into a situation that those who have money will
pay effectively in case we are not able to quickly assess that risk is
really low.

I personally think that having such information ("we know about CVE-XXX and
invite our commercial users to get more certainty") will make it much more
transparent, open and inviting for commercial users. Also it will allow
multiple users of ours to band together - and for example via some
3rd-party companies and services put the money to a common "pot" that those
3rd-parties might use to pay for investing (either in audit or fixing such
bugs). For me it would be an ideal situation and this is something I am
looking for feedback on. I know it's early and probably not something easy
to act on (going through product managers etc.),. This for example would
make a great business case for companies like Lars' . They could say "here
is the issue that needs attention, PMC says it is something that someone
should pay for - so let's collect some money from the interested users and
fund the work". For me this is a fantastic opportunity for us to make it a
viable business, get more funding into the OSS and educate our users that
"OSS is free software. And that's it. Generally you need to pay for things
around the software if you expect more than just software". And to fund
individual contributors / experts who might be engaged (and paid for) to
spend their time on fixing the issues. EVERYONE IS HAPPY. Unicorns and
rainbows.

Of course we cannot endorse companies like Lars' - we cannot say "go to
this company to get it fixed". But we can say "Here are the things you
should look for" and then let companies like Lars' to do all the marketing,
setting up business relationships, collecting money and funneling them to
multiple projects (finding and funding the right people to work on the
issues) - generally making sure that the money find their way to things
that need the attention (and money) of commercial users (and of course take
their cut, which will make it a viable business model). The more I think
about it - the more obvious it is that it SHOULD be done this way.


> From the legal side of things, this is covered in the Apache license. Use
> of software under the ASL section 8 Limitation of Liability (in short form)
> states "use at your own risk". If there is a known vulnerability in a
> dependency, as you mention in the second case, but you don't think it
> creates an issue, your first statement seems to hit most of what needs to
> be said. "We are aware of the CVE-2023-46136 vulnerability in Werkzeug. We
> currently have no reports with scenarios exploiting it and we believe it is
> unlikely it affects Airflow." For your commercial uses, have a more
> detailed statement as to why it is unlikely to cause an issue. I'm not a
> programmer but issue 2 appears to be a stack overflow issue but requires
> outside input to cause the overflow. If the dependency is protected and
> never receives data input from outside that particular module, stating
> something to that effect might be all that is required.
>

Yes. And I think we should do more of it. I think as engineers and
organisations we have really big difficulty in saying "I do not know, but
if you pay, we might be able to find out". This happens all the time and
it's often the case that people expect clear answers from "experts". But
REAL EXPERTS always know when to say "As an expert, I do not know for sure
- but if you pay for my time, I might actually even find out".  I run a
software house for many years and "Estimating the project" was something
our customers always wanted to get for free often saying "Well, you are the
experts, you should know" - but we spent a lot of time and effort educating
our users (and it worked in many cases) that they have to pay - for POC, or
workshops with them to get more educated answers. And it worked even with
big customers. And to be perfectly honest - we are in a MUCH better
situation in our relationship with our commercial users. They might push us
to get answers, but they cannot FORCE US. We can be very assertive. They
cannot really (usually) go to competition. There is no-one else to go to.
They have no choice but to listen to us and if we have a viable proposal
that is good for everyone, this is a very fair game. If we tell them - here
is the way how you can deal with it - by investing into fixing an issue ,
they will have no choice but to comply. And it's a great business
opportunity for 3rd-parties to make business out of that to make it easier
for them to put the money to solve many of those problems.


> Software is potentially always 'hackable' by unknown exploits. There is no
> such thing as being 100% certain that a given program is and always will be
> secure.
>

Absolutely. This is all a "continuum of risk game" and we cannot let it be
turned into a 0/1 game where all the risk and cost is put on us.

J.

Reply via email to