Quote from: mathgal23 on September 08, 2019, 09:07:59 PM

Its hard to have a technical argument with someone that quotes news articles instead of code. See the Hackerone and or GitHub sources that show the issues being resolved:

https://hackerone.com/monero/hacktivity?order_direction=DESC&order_field=popular&filter=type%3Aall
https://github.com/monero-project/monero/commit/1d5e8f461de0a04891e5e18b0f50e9cf2cf534e1

I'm not talking about the issues that have been resolved with the june update (v0.14.1.0), i'm talking
about the issue that did not get resolved in that update (the last remaining security vulnerability that got
classified and not included into the june update)

There is zero information about this security vulnerability and since Monero is still at v0.14.1.0
(some three months now) this security vulnerability (whatever it is) cant have been resolved
as updates go through github (which is still at v0.14.1.0)

Also think about the meaning of classifying a security vulnerability, this basicly means no public information will be released
about this specific security vulnerability untill it gets resolved, which means it will not be on any public lists or github as to not
give any hackers insight into that security vulnerability. I'm mostly surprised that this one has been classified for three months
now with no end in sight.

Maybe its wise to first gather more information from the Monero Core Developers about this last remaining classified
security vulnerability, so that it can be identified in a future update as indeed having been resolved.
Reading that this vulnerability is mostly classified (not completely classified), there should be some details available that can be shared
with the public for identification purpose (without giving hackers any usefull information).

Edit : i think i found a reference to this classified not-yet-resolved security vulnerability

https://thenextweb.com/hardfork/2019/07/04/monero-cryptocurrency-security-flaw-bug-hackerone-disclosure-hack/

Reference : keejef (the one with the blanked out description, due to its classified status i assume).
Closed does not mean resolved, as you can see with the other security vulnerabilities that indeed got resolved and disclosed (the other eight).

As the article mentions only two of the nine security vulnerabilities were of critical status, it does not seem this classified one
is of critical status (two others are according above picture). Which means the classified one could range from low to high status.

To conclude, a quotation from referenced article :

Quote

The bulk of these bugs was submitted roughly four months ago. Eight vulnerabilities have since been patched,
while one remains almost entirely undisclosed. The reports appear to be timed to coincide with the release of
Monero version 0.14.1.0 in June.

Update : i did some further digging and it looks like the classified security vulnerability from keejef has only recentely (28 days ago)
been properly disclosed and merged with Monero's github master. Since it was only an update to the readme.md it does not require a new
software version, which explains why the Monero master on github is still at v0.14.1.0

Whether this disclosure through an update in the readme.md is enough to inform the Monero users about this specific high severity labeled
security vulnerability, i will leave for the readers to decide.

https://github.com/monero-project/monero/pull/5701

readme.md

Quote

### Blockchain-based
Certain blockchain "features" can be considered "bugs" if misused correctly. Consequently, please consider the following:

- When receiving monero, be aware that it may be locked for an arbitrary time if the sender elected to, preventing you from spending that
monero until the lock time expires. You may want to hold off acting upon such a transaction until the unlock time lapses. To get a sense of
that time, you can consider the remaining blocktime until unlock as seen in the `show_transfers` command.

That is if the keejef reference on above picture (the one thats blanked out), actually refers to : https://hackerone.com/reports/417515

It is just weird to see that Monero users can put a timelock on their transactions and thereby totally screw the receiver, by making that
transaction effectively unspendable. I can see two types of attack situations : used against exchanges, used against unaware Monero users.

The way that this security vulnerability got resolved is by pointing the responsebility directly towards the users and exchanges instead of
changing how the timelock of transactions is handled in the Monero code. Time will tell if that is the right approach.