kxxt

It would be more interesting to see the release of the desktop application of open-source Euro-Office because the CEF binary used in "open-source" OnlyOffice desktop application is proprietary.

I have requested [1] the source of the CEF binary for at least two times, with no luck.

[1]: https://github.com/ONLYOFFICE-data/build_tools_data/issues/4

It's because CRLs/OCSP sucks so now short expiration is rolling out.

tracexec uses BPF to some extent, but probably not in the way you guessed. it uses ptrace to do most of the work and use seccomp-bpf to speed it up. Using eBPF to do the syscall filtering requires root, so that's a reason for me to choose ptrace. And credits to the strace developers: https://pchaigno.github.io/strace/2019/10/02/introducing-str...

Yes, it's a very high priority todo for me: https://github.com/kxxt/tracexec/issues/3. I already reserved space for it(The empty line under title in the TUI). It requires some work because for now the environment panel is just a paragraph of text wrapped in a scrollview.

ChatGPT can be a helpful reviewer but it can also give you miss leading suggestions. But it seems that it doesn't know how to properly write a patch.

Recently I participated in Geekgame 2nd, which is a pretty good CTF competition for CTF newbies like me.

One problem in that competition is to submit a safe rust program that will segfault. The problem forces you to begin your rust code by #![forbid(unsafe_code)], which can’t be worked around by #![allow(unsafe_code)].

Of course, there is an attribute `allow_internal_unsafe` which allows you to use unsafe code inside a macro.

But after this PR(https://github.com/rust-lang/rust/pull/57467) was merged, you can no longer use this attribute when unsafe code is forbidden.

So how can you cause a segfault in safe rust under the assumption that you can not bypass #![forbid(unsafe_code)].

...

Read the complete blog by clicking the link in the title.