Rsync client-side arbitrary file write vulnerability

Re:Rsync client-side arbitrary file write vulnerability by dboreham on Tuesday August 02, 2022 @11:44AM (#32320122)

My review of that PR would be : "where's the test for this parsing code?".

I'd expect to see many test inputs that are both valid and invalid.

Note: I'm very much not a testing freak, but for this kind of code I think it's essential to have unit tests, if only because they provide necessary documentation about the intended functionality of the code.

[ Parent | on HN ]

Re:Rsync client-side arbitrary file write vulnerability by trasz on Tuesday August 02, 2022 @01:28PM (#32321725)

If you wrote a code that contains some bug, usually your your tests won’t catch it either. You’d need a fuzzer instead. But then again, it just doesn’t work this way - you can’t write perfect code, you need to follow the principle of least privilege, ie use compartmentalisation.

[ Parent | on HN ]

Re:Rsync client-side arbitrary file write vulnerability by e12e on Tuesday August 02, 2022 @06:36PM (#32325154)

Well, using a fuzzer would probably be a good idea? See eg:

> Fuzzing 100+ open source projects with OSS-Fuzz - lessons learned. (2021)

https://adalogics.com/blog/fuzzing-100-open-source-projects-...

Short hn discussion of post (but project has been featured many times):

https://news.ycombinator.com/item?id=28391620

[ Parent | on HN ]

Re:Rsync client-side arbitrary file write vulnerability by water8 on Tuesday August 02, 2022 @03:03PM (#32322910)

What’s the point of compartmentalization, if all your airlocks are broken or unsecured?

[ Parent | on HN ]

Re:Rsync client-side arbitrary file write vulnerability by trasz on Thursday August 04, 2022 @03:33PM (#32347273)

Its not compartmentalization if your airlocks are broken or unsecured.

[ Parent | on HN ]