In this case I would allow values for the second hour digit from 0-9, so that a time of 19:59:59 could be set. This could break in 12 hour clock countries but users would be able to set all hours in 24 hour countries.
2 Likes
If your timescale is apparent solar time (which is rather unlikely), then 24:00:29.9 is a valid time, as the solar day varies in length according to where the Earth is in its orbit around the Sun. Longest solar day is on or around 22nd December.
Even if not using that timescale, UTC has the possibility of 23:59:60 when adding a leap second. This catches out a lot of people.
Assumptions about time catch out a lot of programmers.
There are a lot of possible problems in accepting input in a locale's time and converting it to system time. I do not envy people trying to do it properly and comprehensively.
I will not argue against you explanation about the different timescales, thanks for the clarification. However, I do not think those concepts can / must be applied here.
This is about the start/stop "time" for a firewall rule, and the users will expect this value to correspond to "watch time", not "solar time", or take into account leap seconds. Besides, if we accept other timescales, then all the other elements involved should also accept them.
In the context of start- and stop- times for firewall rules, then yes, it is a simpler problem.
However, there is one edge case that might be relevant. Leap seconds can be removed, as well as added, and it is possible that one will be removed in the next few years as the Earth is speeding up its rotation. This means that it is possible that UTC will officially 'jump' from 23:59:58 to 00:00:00 at some point in the future. Depending on the behaviour of the system clock, this might or might not cause a problem if a rule is due to start or stop at 23:59:59.
I would argue that accepting a time of 24:00:00 is helpful, as it refers to the midnight after 00:00:00 and removes ambiguity. Although not relevant to this case, there are places in the world that routinely use times beyond 24:00:00 to indicate a time in the early morning of the following day: for example nightclubs advertising opening hours; and some public transport timetables.
If you wanted a firewall rule to start at office closing time (e.g. 17:00) and continue until office opening time the following day (e.g. 08:00), it would make sense in a single rule to allow a stop 'time' of 32:00:00, so the rule is from 17:00:00 to 32:00:00. The alternative is a rule that starts at 17:00:00, finishes at 23:59:59; then a second rule that starts at 00:00:00 and finishes at 08:00:00, which is ungainly, and misses a second, and unnecessarily turns the rule off and on in the middle of its validity. A longer period might be needed to cover a weekend, or even a longer public holiday, which in the UK could be up to 4 consecutive days over Christmas, and in some European countries 5 consecutive days over Easter.
Another way of achieving the same end would be to define rules with a start time and a duration, which could exceed 24 hours.
This means that being able to input numbers greater the 23 in the 'hours' field might not be a bug, but a feature.
I have two different kitchen timers with keypads that allow me to enter a 'time' of 9h99m99s - which is convenient if I am counting more than 59 minutes. When started it decrements the seconds to zero, then subsequently continuing from 59 for each additional minute; and similarly the minutes to zero, then continuing from 59 for each additional hour as the hours decrement.
Dealing with input of times, durations, and regular events is tricky.
I think that this is always a sensible approach that removes a lot of potential issues.
So this release has been running on an AVM FRITZ!Box 7520 for literal months on end making an absolutely flawless VDSL router without requiring any user intervention whatsoever.
Frankly, it is getting suspicious.
Have you developers or maintainers sold any souls or firstborns?
No, it's those who write the code for commercial products who sold their soul... 
Man got to eat… and provide! Respect.
Sure. Clearly, it was tongue in cheek and a joke about reversing what he meant with selling one's soul, hence the smiley.
Still, it really is striking how better a completely free router firmware works and performs compared to products that cost pretty decent money.
1 Like
Yes very true. I think partly it might be because paid work is limited by payment. No more payment, no more work. So many workers will leave at the end of the working day and not work much more. Whereas projects like OpenWrt benefit from unbridled enthusiasm that is not so constrained.
2 Likes
An important part of it is due to bad management at many commercial firms.
As demonstrated by open source projects, people who enjoy their work are happy to even work for free if they have the motivation. But nothing kills motivation more than bad management.
7 Likes
Given the ksmbd vulnerabilities disclosed recently and needing kernel fixes - are there any plans for a security release?
https://www.openwall.com/lists/oss-security/2024/03/18/2
P.S. My router is unaffected, as I use SAMBA, not ksmbd, exactly because of stability problems (kernel panics) triggered in the past by normal use.
@patrakov yes we are near a release, can you check and confirm if those CVE received backport for stable kernel or we need to backport them manually?
I have checked:
- CVE-2023-52440, CVE-2023-52441, CVE-2023-52442 are fixed in 5.15.145
- CVE-2024-26592, CVE-2024-26594 are fixed in 5.15.149
So - yes, the fixes are already in the openwrt-23.05 git branch.
2 Likes
thanks for checking... a release should happen this week if everything goes well.
13 Likes
Although not affected by those, Samba could use a bump too, there are a lot of bug/CVE fixes on the main branch 4.19.5 for that too
I don't think that switching the SAMBA branch from 4.18 to 4.19 is appropriate for a minor OpenWrt release. 4.18.x is still supported upstream.
In any case, updating SAMBA is not as important as updating the kernel, as any bugs in userspace packages can be fixed post-release and applied via attended-susupgrade while still staying (on paper) on the same release.
Either way, the differences are minor between 4.18/4.19, just a lot of bug/CVEs fixed.
Please don't create expectations on releases.
2024/02/13 was written that 23.05.3 release is planned in 2 weeks.
I'd rather be surprised then waiting and wondering if all went well / what's wrong.
No expectations... the current blocker is dnsmasq and we need to take a decision on that. Just answering with what is said in openwrt-adm
8 Likes