It didn't compress the data. It understood it is an artificial sound file, reverse engineered it, and then encoded the source if it instead of compressing the output
205 karma · joined February 15, 2019
My personal experience as a software engineer, and a former security researcher who did manual code audit, is that this code review tool has such poor results that it isn't worth the "noise" and friction it causes developers during C/I code review
MRC, which is already being used by OAI in production for training their models, aims to provide robust network utilization, allowing improved bandwidth while also efficiently handling network failures automatically at routing level.
Hence, for a "file-sections" flag, we would only resolve relocations within a given file, but will leave intact relocations that cross the file boundary. Accordingly, this means that "function-sections" is identical to generating a static bundle object per original object file, and bundling them all together inside a .a archive.
This is the current intention, as implemented in the up-to-date draft: https://github.com/bminor/binutils-gdb/commit/99aef6ba8db670.... Please note however that one would no longer need to specify the "--whole-archive" flag, hence resolving issues with potential duplicate placement of the static library in the linker's CLI.
> Are there cases in which function-sections doesn't work (GCs too much) but a hypothetical "file-sections" does? For example cases in which the code relies on side effects of global constructors, but those would be left out by function-sections?
Good question. In the first article in this series I discussed issues with global constructors and was pretty much waved away, being told that code should not be written this way. One of the members of the ELF committee did suggest an alternative for handling it yet pretty much mentioned that there are still missing pieces that require handling for their proposal to work (https://groups.google.com/g/generic-abi/c/sT25-xfX9yc/m/NRo0...).
The key point in the proposal for a static-bundle-object is to properly handle static libraries as linked objects, instead of as a bunch of plain .o files.
I hope that once integrated to linkers the adoption of this new format will help convince that it deserves significantly better tooling.
While the previous article presented the problem domain (multiple issues with using .a archives of plain object-code files for static libraries), this article presents the technical white paper that formally proposes an alternative format (accompanied by a POC on top of GNU's ld), as well as the gist of the ELF committee's discussion about the proposal.
Given the decision of the ELF committee, the format will be judged by adoption in practice and the feedback it receives from users. In other words, your opinion is more than welcome.
Isn't this policy overruling the judgement of the team/product lead and focuses too much "only" on the bugs?
Aside from that, while it might seem like an ideal engineering culture, I find it a bit extreme. The harsh SLA leaves little room for prioritization. Sometime the team is in fact working on a tough integration deadline, and medium-level bugs can wait for it to finish.
Going over my current list of bugs, some are minor and can wait to the last mile of the release and some will be resolved by new features we have in planning. I do aim to minimize the list of bugs and even my email inbox is based on a "zero inbox" policy. Still "zero" in this case is some small epsilon that is under control, and will go down to zero if no new bugs/emails arrive in the meantime. Call it a sliding window of epsilon width, but it almost never really reaches zero.
Propagating the fix downstream depends on the release cycles of all downward vendors. Giving them a heads up will help planning, but I doubt it will significantly impact the patching timeline.
It is highly more likely that companies will get stressed that the public knows they have a vulnerability, while they are still working to fix it. The pressure from these companies will probably shut this policy change down.
Also, will this policy apply also to Google's own products?
If pkg-config was never meant to be consumed directly, and was always meant to be post processed, then we are missing this post processing tool. Reinventing it in every compilation technology again and again is suboptimal, and at least Make and CMake do not have this post processing support.
Also, some managers object to a prefix within non-api functions, and frankly I can understand them.
I'm impressed by the effort on Google's side, yet I'll be surprised if this effort will pay off.
The article describes the technical background about the "Reverse RDP" attack vector, the software design flaw in FreeRDP and the security patch that was integrated into the project (and that took 2 years to get officially released to the public).
It happens so fast behind the scenes that the user isn't aware of it, and it makes sure I won't have to guess anything when I play. Purely skill, no random.