* Mathias Behrle [2018-02-16 16:22 +0100]:
* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed,
14 Feb 2018 13:55:48 +0100):
Hello again,
Hello Matthias,
* Mathias Behrle [2018-02-14 12:17 +0100]:
* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed,
14 Feb 2018 10:46:38 +0100):
Hi together,
Hello,
I am still missing a thorough handling of the _several_ _different_ involved
issues as proposed in
https://bugs.tryton.org/issue5375 (specifically
https://bugs.tryton.org/msg24691)
Quite frankly I don't think there is much to discuss in this message.
But you might elaborate more on the issue so that I can understand
what should be discussed.
There are 3 topics explicitely identified. Could you please elaborate
what you don't understand?
According to me those three topics are either already discussed (the
delay and the vulnerability) or I don't see what you want to discuss
about those (the password security).
and
https://bugs.tryton.org/issue7111 (specifically
https://bugs.tryton.org/msg38228)
- Session management: there is a recent issue about that
To which issue are you refering exactly, a quick search on the bugtracker
didn't reveal any hit [1]?
issue7134
- Login delay: we can discuss it at length, the policy we have
won't change for the reasons exposed by Cédric in another email
But as my review on appspot displays if people want they can use
a different strategy.
Thanks for that. It is a bit complicated to find that review under a
totally unrelated topic (Remove openSUSE packages)
https://bugs.tryton.org/issue7111 >
https://bugs.tryton.org/msg38228 >
https://bugzilla.opensuse.org/show_bug.cgi?id=1078111 >
https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c19 >
https://codereview.appspot.com/335550043/
Wouldn't it be worth to post that example of a possible modification
on a more prominent place?
You can do whatever you want with this review.
- Usability aspects: I don't understand what you mean
You shortened the complete sentence which was
- Usability aspects (as in punishment of wrong password entries and with regard
to distributions in general)
I want to elaborate on the two given examples:
- punishment of wrong password entries
While there was a lot of input and I would say agreement, that
there *has* to be a login delay, there was never agreement about
the duration. The exponential login timeout in terms of brute force
attack is fairly oversized.
What makes you think so?
I think it's a pretty clever way to delay brute force attacks.
So when you want to keep that absolutely we comes to usability
aspects in terms of user friendlyness: a well concepted login
manager (e.g. on android) doesn't let the user in the dark, but
tells him, that after a failed login he has to wait for x seconds
and then counts them down. The Tryton GTK-interface instead just
goes unresponsive giving the impression of a hanging application.
There is great probability that a half-experienced user will just
hard kill it, because he thinks there is going something wrong.
That might be a good idea, any patch implementing this would be
welcome.
- and with regard to distributions in general
Speaking with my Debian maintainer hat on I consider the step taken in
https://bugs.tryton.org/issue7111 as regrettably and wrong.
- I can not see how the mere *listing* of distributions on the
website can be considered an *advice*.
Just like debian cares about the security of its users, we should care
about the security of ours.
This patch was hindering the brute force protection mechanism. We had
the option of not saying anything, warning our users or remove the
package. The foundation opted for the last choice. Not everybody
justified their vote but I can tell you why I voted this way: I didn't
want to shame the maintainer of the package because of a choice he
made. So the least impactfull solution was to remove the package.
- Shouldn't it be just a sign of mutual respect for both sides?
Distributions should be happy about the existence of Tryton and
in the same way Tryton should be glad to be recognized and
integrated into the major distributions. Glad to here your and
the general input on this subject.
We're happy to be packaged of course but when there is a choice to be
made between the security of our users or the distribution, I will
always put the priority on our users.
- Compared to some other security related topics issue7111 is highly
exaggerated. What will the foundation or the maintainer do about
sao where the maintained series will be affected by a
security-wise unmaintained jquery version?
Are you comparing a brute force attack to a bug filled 18month ago
about a library that was not at that time deprecated? Seriously?
Have a look at https://bugs.tryton.org/issue5925 which was created
at 2016-10-03.16:09:27. The referenced issue [2] to justify the
now impending upgrade dates from 2016-10-06. It was already clear
at the time of the creation of issue5925 that bootstrap 3.3.7
supports jquery 3+, but there was no action taken.
This bugs is apparently very important for you. You can be sure any
patch migrating to jquery 4 you will submit will be taken into account.
Sao now will suffer in all currently maintained stable series
from the usage of an unsupported jquery version.
Will that lead to a big fat warning on the website or to the
removal of sao <= 4.6?
Of course not. Just like there is no warning on the debian website
about using GTK2.
- Hardening of trytond against brute force attack: It's linked to
the login delay. If you're able to display another kind of
attack vector please open a security issue
I would have prefered to have the discussion at discuss.tryton.org or at
least bugs.tryton.org. Unfortunately the further discussion of this topic
happened on the OpenSUSE tracker.The last comment is
https://bugzilla.opensuse.org/show_bug.cgi?id=1078111#c22
with the proposal of a patch that is uncommented so far.
The patch is uncommented indeed. I have other things to do than
comment on everything the day after it has been posted, I hope you can
understand that.
I took a quick look at the patch. It removes the exponential wait
which is already a bad sign. Moreover it does nothing that couldn't be
done by overriding LoginAttempt in GNU Health.
We have differing opinions about the severity of the issue. Mechanisms
have been put to diminish even further its severity. And unfortunately
I don't think those opinions can be reconciled.
- Hardening trytond agains DDOS attack: we can also discuss it at
length on the mailing list but in the end we all agree that it
involves a lot of different systems and there is not really a
final solution to this issue
A lot of different systems involved, true. Especially when Tryton
loads off the resource limits to the database backend. Unfortunately
the interest of the maintainer to put that load off to other
configurable backends seems to be non-existent. This is at least what
I got for a proposal pointing this way earlier in this thread:
nothing.
As I said: people can override LoginAttempt and define their own
add/count/etc methods. It's already there.
- Responsibility about decision taking in the project: It should
be a new thread. Ideally it should be a community decision but
the problem arise when there is no clear consensus, in this case
I see two realms:
- the marketing (website, twitter, etc): the foundation has
the last word
- the code: Cédric has the last word
Since the beginning the project is based on a BDFL style and I
think that's the best way to do it. It's inspired by python
and numerous other projects that work this way.
My personal view from reading the foundation statutes [3] is that the
foundation is empowered to much more than just marketing.
It's in French:
La fondation a pour but la protection, la promotion et le
développement du logiciel libre dénommé Tryton.
Afin de réaliser ce but, la fondation aura principalement pour
activités:
- l'organisation de conférences, colloques ou tout autre
événements (etc)
- l'organisation de la communauté de sympathisants (etc)
- la gestion de l'ensemble des outils collaboratifs (etc)
- la gestion de l'administration permettant la promotion et la
pérennisation de la marque déposée Tryton.
La fondation peut accomplir tous les actes se rapportant
directment ou indirectement à son objet.
So it's mainly organizing the community, promoting tryton and managing
the infrastructure and trademark.
I will appreciate a public statement of the foundation which
responsibilities are covered by its work.
I think the status defines broadly what the foundation do.
- Attitude and mindset towards downstream / distribution:
- We could promote more downstream users of Tryton, yet we
have business cases and nothing prevents anyone of
submitting new cases according to our rules. We have one
about coog, I would be delighted to have one about a GNU
Health implementation.
- distribution: The fact that distributions package Tryton is
obviously a good thing. But on the other hand I think we can
not let pass some patches that hinders the security of
Tryton.
You want a business case about GNU Health *on the website*, but you
exclude the OpenSUSE packages *from the website*, because they
applied a patch coming from the GNU Health side? I feel that to be
highly contradictory.
People using GNU Health don't have to apply this patch you know.
And of course, I still consider GNU Health as a valid usage of Tryton.
I disagree with Luis about a patch that he's applying but the overall
functionality seems sound and an excellent exemple of what Tryton is
able to do.
For the role of distributions in general: they are just other
downstreams like consumers, developers. They have exactly the same
right to change and distribute the code under the GPL licence of the
project. It is completely understood that distributions adapt
upstream software to fit into the distribution and to do whatelse
they deem to be necessary. There is absolutely no mean and there
shouldn't even be the intention to take responsibility about changes
made to the code. When indeed you think 'we can not let pass some
patches that hinders the security of Tryton' you are severely out of
control and you want Tryton to have a different licence.
Not at all. You're putting thoughts on my mind without asking me.
People can do whatever they want with the code as long as they follow
the GPL. But we don't have a duty to reference them on our download
page either. And if we find that the patches that are applied by a
distribution is harmful towards our users then we have the right to
remove this distribution from the download page.
The distribution have some liberties, but we as a project we also some
liberties.
Let me cite from COPYRIGHT:
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
In this light the decision taken at https://bugs.tryton.org/issue7111
is defintely the wrong way and is just the beginning of taking a
responsibility that the project shouldn't want neither will be able
to fulfil at any time.
You're interpreting this decision wrong.
We just don't want to put on the download page distributions applying
patches harmful for our users.
I think we all agree that it is better to catch (D)DoS on the server
level instead of the database level, i.e. when undergoing a DDoS
attack the Tryton server or its authentication backend should catch
the load and eventually go unresponsive, but not the database
backend. I think many of the concerns presented by Luis and by Axel
could be mitigated by the implementation of an optional session
management bypassing the production database.
Thoughts?
I think there is already numerous ways to mitigate the concerns
presented by Axel and Luis. This patch might help a bit too.
Which patch are you exactly refering to?
The patch overriding LoginAttempt.
Anyway happy to see that you seem to agree on the usefulness of a
separate authentication backend like redis.
redis is not an authentication backend.
I won't code an authentication backend on redis for you neither.
If you want one, code one.
I am exclusively talking about the "OpenSUSE packaging of trytond
issue".
There are solution for this without the need to discuss the other
issues. It does not mean that the other issues are not worth
discussing or that they should be pushed under the rug. No, I just
want to state that there are other ways to fix this specific issue
then applying a controversial patch to trytond.
AFAIS there are several related issues that led to the application of
the said patch on the OpenSUSE side.
I don't know I am not in their mind.
Thus it is not just one issue.
The fact is that it is just one issue. One patch that Luis thinks
should be applied on trytond while we think it should be solved by
overriding LoginAttempt.
Then the way I see it is that from this issue there has been some
agenda pushing: to remove the OpenSUSE package, to discuss the role of
the foundation, etc.
I tried to keep in my mind the good of our users and to solve the
issue and the discussions that arose from the issue for them.
--
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas.evr...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/
--
You received this message because you are subscribed to the Google Groups
"tryton-dev" group.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tryton-dev/20180216173203.ol2pe663udmvgbw7%40localhost.localdomain.
