rnijveld

18 ms·

1.
by rnijveld 7d ago
I would say there is a significant difference between AI discovering this completely on its own versus AI creating the finishing connecting part by connecting relevant data. Maybe this claim is too strong, but if part of it is true then the
2.
by rnijveld 3mo ago
I find this a very weird way of formulating this. Even if AI keeps its promises and is the future of computing (hopefully without destroying the environment), should it not be applauded that there are still organizations funding work in non
3.
by rnijveld 5mo ago
You realize this article talks about Rust on embedded hardware specifically, where you don’t have threads or big runtimes? There is no hate going on here either, just attempts to make things better. Might I suggest you click through to the
4.
Three Years of Rusty Sudo(trifectatech.org)
1 points by rnijveld 5mo ago|0 comments
5.
by rnijveld 10mo ago
As someone working on an NTP implementation (specifically ntpd-rs) I have to add some context to this: I do believe that donating to the Network Time Foundation is fine, but it is not required to keep the Network Time Protocol up in any way
6.
by rnijveld 10mo ago
The ntp pool is actually independently run and funded and has nothing to do with the NTPd implementation nor the NTP Foundation, other than them allowing the pool to use that DNS name.
7.
by rnijveld 1y ago
The features we specifically don’t support are those related to direct LDAP support within sudo, so things like loading a sudoers file directly from LDAP. Sudo-rs will use any user retrieved via NSS, such as when configured using SSSD to lo
8.
by rnijveld 2y ago
I would argue compile time changes don't matter much, as the amount of data going through zlib all across the world is so large, that any performance gain should more than compensate any additional compilation time (and zlib-rs compile
9.
by rnijveld 2y ago
Ah right! I always forget about that since we don’t implement the management protocol in ntpd-rs. I think it’s insane that stuff should go over the same socket as the normal time messages. Something I don’t ever see us implementing.
10.
by rnijveld 2y ago
Probably, but we still need to parse that string on the client side as well. If you’re willing to do the work I’m sure we would accept a pull request for it! There’s just so many things to do in so little time unfortunately. I think reducin
11.
by rnijveld 2y ago
I also agree that there is too much churn in the Rust ecosystem and that we should try and slow things down in the coming years. ntpd-rs also does this: our MSRV is 1.70 right now (that was released over a year ago) and we test our code on
12.
by rnijveld 2y ago
I'm afraid this is a pretty common sentiment. NTS has been out for several years already and is implemented in several implementations (including our ntpd-rs implementation, and others like chrony and ntpsec). Yet its usage is low and
13.
by rnijveld 2y ago
Our project also includes a PTP implementation, statime ( https://github.com/pendulum-project/statime/ ), that includes a Linux daemon. Our implementation should work as well or even better than what linuxptp does,
14.
by rnijveld 2y ago
I do think that memory safety is important for any network service. The probability of something going horribly wrong when a network packet is parsed in a wrong way is just too high. NTP typically does have more access to the host OS than o
15.
by rnijveld 2y ago
I agree that amplification and reflection definitely are worries, which is why we are working towards NTS becoming a default on the internet. NTS would prevent responses by a server from a spoofed packet and at the same time would make sure
16.
by rnijveld 2y ago
I don’t think our dependency tree is perfect, but I think our dependencies are reasonable overall. We use JSON for transferring metrics data from our NTP daemon to our prometheus metrics daemon. We’ve made this split for security reasons, w
17.
by rnijveld 2y ago
I would encourage you to take a look at some of our testing data and an explanation of our algorithm in our repository ( https://github.com/pendulum-project/ntpd-rs/tree/main/docs/a... ). I think we a
18.
by rnijveld 2y ago
In our internal testing we are very close to Chrony with our synchronization performance, some of our testing data and an explanation of our algorithm is published in our repository: https://github.com/pendulum-project/
19.
by rnijveld 2y ago
This only works on Linux of course since the Linux kernel and libc are not tightly coupled, on any other OS dynamically linking against libc is a necessity. Also, I've never seen anyone statically linking against glibc? Is that even so
20.
by rnijveld 2y ago
I'd like to respond to a few things. I think using dependency count as a metric is a bad idea, that metric could easily be lowered by just copying all the code over to your project. As you rightfully say, the logic has to exist one way
21.
by rnijveld 3y ago
I can only thank you for the work you've done in creating sudo, I think it's an invaluable tool in the general day to day use for so many people. As someone working on sudo-rs, our goal with creating it never was to invalidate any
22.
by rnijveld 3y ago
They don’t have to be though, a yubikey can be used as a passkey as well.
23.
by rnijveld 3y ago
We did indeed look at and are still looking at the list of CVEs where sudo takes part right now. However, many of the bugs are through one way or another not applicable for our implementation (yet). For example CVE-2014-0106 is only applica
24.
by rnijveld 3y ago
I’m on the sudo-rs team: we are actually very mindful of the dependencies we use. Our current main branch already uses significantly fewer dependencies than a few months ago. Aside from security it also really helps with adoption since it m
25.
by rnijveld 3y ago
We’d love to get a report for this! While we are sure we will make bugs (which is also why we have the notice up on the repository, and you have to go through some hoops in order to use it), we also think that we can try and come up with an
26.
by rnijveld 3y ago
I’m on the team that is creating sudo-rs. I agree that just assuming that memory safety will get rid of all the bugs is just plain wrong, it will prevent some particular classes of bugs, but that is all it does. But we do think that sudo in
27.
by rnijveld 3y ago
I think your expectations are too high. During our initial exploration we actually managed to talk to Todd Miller, the maintainer of sudo. In our (brief) interactions with him he did not sound cavalier like this at all. Instead I think that
28.
by rnijveld 3y ago
Definitely one of the things that is on our radar! Lots of features in sudo are just basically legacy features, remnants from the 90s or 00s that are no longer necessary in a modern setup, but nevertheless exist because in past times they u
29.
by rnijveld 3y ago
I’m on the team that is implementing sudo-rs, and we are definitely aware of doas and other similar utilities. Doas does definitely have its usages, especially with the ‘just let me run this as root’ use case in mind. That said, there is al
30.
by rnijveld 3y ago
I’m one of the people working on this. While I do think that the memory safety aspect is an important one, I think that one thing where we can win even more is that Rust has a type system that is much more robust than what C offers. If set

More ›