Re: [tryton-dev] Impact mitigation for DDoS attack
* 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
Re: [tryton-dev] Impact mitigation for DDoS attack
* Nicolas Évrard: " Re: [tryton-dev] Impact mitigation for DDoS attack" (Wed, 14 Feb 2018 13:55:48 +0100): Hello again, > * 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? >>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]? > - 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? > - 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. 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. - 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*. - 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. - 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? 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. 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? > - 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. > - 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.
Re: [tryton-dev] Call a Functional Field from another module
On 2018-02-15 11:53, Josias Pérez wrote:
> Hi,
>
> I would appreciate if could tell how I can call a functional field from
> another module, in this case, I need to call the payable function field from
> account module.
>
> The code is the follow:
>
> currency_digits = fields.Function(fields.Integer('Currency Digits'),
> 'get_currency_digits')
>
> receivable = fields.Function(
> fields.Numeric('Por cobrar',
> digits=(16, Eval('currency_digits', 2)),
> depends=['currency_digits']),
> 'get_receivable_payable')
>
> @classmethod
> def get_currency_digits(cls, parties, name):
> pool = Pool()
> Company = pool.get('company.company')
> company_id = Transaction().context.get('company')
> if company_id:
> company = Company(company_id)
> digits = company.currency.digits
> else:
> digits = 2
> return {p.id: digits for p in parties}
>
> @classmethod
> def get_receivable_payable(cls, subscriptions, names):
> for subscription in subscriptions:
> if subscription.party:
> amount = subscription.party.receivable
> return amount
> else:
> return 0
>
> I'm trying to get the value of the payable field of account module. [1]
You should not try to call getter of Function field directly indeed you
should use the ORM and just access the corresponding field.
--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric.kr...@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/20180216090350.GT24410%40kei.
