May I ask what was the result of this vote was?
2024-02-03 오후 9:06에 Hauke Mehrtens 이(가) 쓴 글:
Hi,
I track the status of the Linux kernel 6.1 migration in this github
issue: https://github.com/openwrt/openwrt/issues/14546
There are still many targets on kernel 5.15 without testing support
for ke
https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.7
https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-security-advisory-2024-01-1/
need to update to 2.28.7 or 3.5.2
made a pull req on main but I think this needs backports too
https://github.com/openwrt/openwrt/pull/145
sorry, use_bcrypt isn't something in mainline busybox but a patched
vesrion so I think sha256 is best option here
2024-01-19 오후 4:28에 abnoeh 이(가) 쓴 글:
that option only applies if we use busybox internal crypt,
BUSYBOX_DEFAULT_USE_BB_CRYPT is set but we don't so it doesn't nee
that option only applies if we use busybox internal crypt,
BUSYBOX_DEFAULT_USE_BB_CRYPT is set but we don't so it doesn't needed
(it's using musl here)
you'd need to change this option (line 1367) on same file
config BUSYBOX_DEFAULT_FEATURE_DEFAULT_PASSWD_ALGO
string
default "md5
old times there was a musl size hack that disabled everything except DES
and md5, but that was disabled in 2021 Dec
https://github.com/openwrt/openwrt/commit/66768755791286fc02a38d1b437a9da74290041d,
allowing sha256,sha512 and blowfish
however Busybox doesn't configed to use those and still use m
wpad-full complies and works (at least in basic wifi setting )
2023-06-18 오후 4:01에 abnoeh 이(가) 쓴 글:
Mbedtls 2.28 is planed to EOL at 2024/12, (as they only keep LTS branch
just for 3 years from 2.7 and 2.16 trees are. so we have 1.5 years for
prepare for it, and they support TLS 1.3
I made
Mbedtls 2.28 is planed to EOL at 2024/12, (as they only keep LTS branch
just for 3 years from 2.7 and 2.16 trees are. so we have 1.5 years for
prepare for it, and they support TLS 1.3
I made this PR on github to openwrt/ustream-ssl can work on mbedtls 3.x
version.
it looksing a deprecated macr
as branch didn't even split won't in next two weeks so it'd be 21.x
maybe fellow debian bullseye freeze date?
https://release.debian.org/bullseye/freeze_policy.html
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.
20. 10. 13. 오후 9:54에 Rui Salvaterra 이(가) 쓴 글:
This allows the user to select only the encryption algorithms (s)he requires
(e.g., disabling AES and keeping only ChaCha20-Poly1305). The default selection
maintains the current functionality.
Additionally, make sure at least one encryption algorit
it was originally part of Re: A proposal of https certificate assignment
system for luci thread but this derailed too much from there.
Nice idea to be able to auto-load the config including key material.
Might be very useful for larger installs.
Nice idea to save SSH server keys as well. That w
20. 10. 9. 오후 8:29에 Bas Mevissen 이(가) 쓴 글:
So I think it is reasonably safe to do the initial setup over HTTP
(without the "S") at the first boot if there are no certificates
available from a previous OpenWRT install. Then the user can setup the
WAN side if needed and upload (from local PC), gen
20. 10. 6. 오전 1:29에 Michael Richardson 이(가) 쓴 글:
abnoeh wrote:
> Openwrt as project get a CA certificate with name constrained to only
> able to sign subdomains of [luci.openwrt.org]. this makes we
> Technically Constrained Subordinate CA, (from let's encrypt or
Few months ago there was some debate for how we handle certificate for
luci page: make user to click though certificate warning is not that
great for security so here is a proposal for autometically assign a
worldwide unique subdomain and how to make valid certificate for it, and
make sure we and
13 matches
Mail list logo
