Hi,
> [...]
> I renamed the new cookies to "http-sysauth" and "https-sysauth", to work
> around this and it seems to do the right thing. But there is still a fault
> here.
Already fixed with
https://github.com/jow-/lucihttp/commit/6e68a1065f3ed1889e5fa053b206bd3aa108bd5f
~ Jow
signature.as
If you are using Bind9 then you should upgrade to the latest (9.18.10-1)
package. No, it's not a CVE. It's a glitch where, if Bind comes up before
your WAN port has stabilized, then you'll end up with bogus SOA and NS records
for your root server keys because of a problem in how the journaled
On Fri, 30 Dec 2022 at 03:41, Jan-Niklas Burfeind wrote:
>
> in both the stable and the testing kernel
>
> h2+/h3/h5 devices have a Secure ID that can be read from
> `/sys/bus/nvmem/devices/sunxi-sid0/nvmem`.
> Enabling CONFIG_NVMEM_SYSFS grants sysfs access from userspace.
>
> Signed-off-by: Jan-
On 12/22/22 15:56, Peter Naulls wrote:
On 12/22/22 13:50, Oscar Hjelm wrote:
I’m not familiar with the luci interface, but to help you get started:
- One workaround would be to use a different cookie name on the new secure
cookies (or a new name on the older cookies, if that is preferred). Th
Hi all!
After a power interrupt the /-directory is read-only:
/dev/mtdblock2 on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mtdblock3 on
