You're right - enabling upload certificates (which work, AFAIK)
would fix the problem too,
as long as the project's upload directory isn't accessible.
If I recall, we made upload certificates not the default at
a point where S@h's servers were overloaded and we were looking
for every performance boost (actually the impact is probably negligible).
-- D
On 11/17/2015 4:04 AM, Christian Beer wrote:
On 17.11.2015 12:24, Nicolás Alvarez wrote:
4. The commit message says the attacker could "upload fake files as B's output
files". This is not possible due to upload signatures. If he could upload fake files
as B's output files, he could also do the same as C's, D's, E's, etc. with file sizes as
large as max_nbytes allows and fill up the upload server, which is exactly what upload
signatures are supposed to prevent.
If the attacker can't upload files as B's output files, the entire postulated
attack falls down and this change is not necessary.
This is for a scenario where the project turned off upload certificates.
This is not mentioned in the message.
So I have another question: What's the argument for turning off upload
certificates and needing this kind of randomized filename? Wouldn't it
be easier to fix and enable upload certificates?
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
