We already moved away from 2048-MODP in Core Update 170. Similarly,
German Federal Office for Information Security (BSI) recommends shifting
away from RSA keys below 3,000 bits by the end of 2022 at the latest.
The only place left in IPFire 2.x where we generate such keys is for
IPsec and OpenVPN host certificates. This patch increases their key
sizes to 4,096 bits as well - CA certificates already have this length.
Existing VPN connections cannot be migrated automatically. However, only
the respective host certificate has to be regenerated - thanks to the CA
certificates' key length being sufficient, there is no need to replace
the entire VPN CA.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
* If a cgi file exists with the same name as an addon, the
displayed service will be a link to that cgi file.
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
* Add restart action to services.
* Only display available actions for a service:
Start when service is stopped or Stop and Restart when a service
is running.
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
* Singular 'Service' instead of plural 'Services' as column header of
services table
* Sort list of services
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
* addonctrl's new functionality to control explicit addon services was
implemented.
* Change 'Addon' column header to 'Addon Service' to be clear that
it's not addons but services listed here.
* Services not matching the name of the addon now display the addon
name between parentheses, so the user knows where the service comes
from.
* When no valid runlevel symlink is found by addonctrl for a service,
the 'enable on boot' checkbox is replaced by a small exclamation point
with alt-text "No valid runlevel symlink was found for the initscript of
this service." to inform user why a service can't be enabled.
* Added German and Dutch translation for above message.
Fixes: Bug#12935
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
- Removed remnant from IPCop on URL Filter Logs Export page.
Signed-off-by: Jon Murphy <jon.murphy@ipfire.org>
Reviewed-by: Bernhard Bitsch <bbitsch@ipfire.org>
The email recipient was not correctly validated which allowed for some
stored cross-site scripting vulnerability.
Fixes: #12925 - JVN#15411362 Inquiry on vulnerability found in IPFire
Reported-by: Noriko Totsuka <vuls@jpcert.or.jp>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf (released in
2015) recommends "to use primes of 2048 bits or larger", to which BSI's
techical guideline BSI-TR-02102 (https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102.pdf?__blob=publicationFile&v=5)
concurs. The latter also recommends not to use DH groups comprising of
less than 2000 bits after 2022, and shift to 3000 bit DH groups earlier
as a precaution.
According to RFC 3526, section 8, MODP-1536 provides an estimated
security between 90 and 120 bits, a value that can be reasonably
considered broken today, as it has been so for other types of
cryptographic algorithms already, and per section 2.4 in the
aforementioned paper, breaking 1024-bit DH is considered feasible for
the NSA in 2015, which does not inspire confidence for MODP-1536 in
2022.
Therefore, this patch suggests to mark MODP-1536 as broken, since it
de facto is, and tag MODP-2048 as weak. The latter is also removed from
the default selection, so newly created VPN connections won't use it
anymore, to follow BSI's recommendations of using DH groups >= 3000 bits
in 2022 and later.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremer@ipfire.org>
- Use getmetadata function in services.cgi to determine installed
addon services to display. Removing code duplication and intel that
should only be known by pakfire itself.
- Removed hardcoded exclusions:
- squid should show up correctly using the new metadata info
- mdadm is part of core and will never show up here
- alsa, unknown if this problem still exists, but if it is, this
should be handled somewhere else.
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
- Removed UI code from dblist function and refactor it making it return
a hash representing the pak db for easier handling of this data.
- Moved core update check in dblist to new seperate dbcoreinfo function
making it return a hash with current and possibly available core
version info.
- Update existing calls to dblist
- Bring UI parts previously in dblist to pakfire program itself,
pakfire.cgi and index.cgi with a few small enhancements:
- Translations for 'Core-Update', 'Release', 'Update' and 'Version'
- Add currently installed version numbers to installed paks list in
pakfire.cgi
- Add 'Installed: yes/no' to pakfire list output so people not using
colors have this information too. (Partly fixes Bug #12868)
- Add update available details to pakfire list output if package has
updates available.
Signed-off-by: Robin Roevens <robin.roevens@disroot.org>
This just came to my view...
I know its not *actually* a link to a "DNS-Proxyserver", but I find it
nice that I can change to the page containing some of the main DNS settings
in just one click. I thought it could be useful.
JM2C
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The support for themes has been removed since ages, so we
do not need this anymore and may crash the page.
Signed-off-by: Rob Brewer <rob.brewer@ipfire.org>
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
This is a little patch which will extend the aliases page to offer an
interface selection if there are more than one RED interfaces.
This is a little hack to make configuration easier for users who have
manually set up more than one RED interface (e.g. for load balancing or
fail-over) and want to use the UI to configure firewall rules.
As a little benefit on the side, I had to rewrite setaliases.c to use
ip(8) instead of ifconfig(8).
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Acked-by: Peter Müller <peter.mueller@ipfire.org>
Since the kernel now always reports 256 bits of entropy to be available,
this CGI does not show any useful information anymore. To avoid
confusions, it will hereby be removed entirely.
Fixes: #12893
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
- The fix for bug #12428 removed spaces from the validhostname subroutine as hostnames are
not supposed to have spaces
- This resulted in spaces no longer being allowed for the Static IP Address Pools names
- New subroutine created called validccdname in general-functions.pl
Fixes: Bug #12865
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
- Patch https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=2feacd989823aa1dbd5844c315a9abfd49060487
from May 2021 put the variable containing the .p12 content into double quotes which
causes the contents to be treated as text whereas the .p12 file is an application file.
- Most people must be downloading the zip package of .p12, ovpn.conf and ta.key files so
the problem was not noticed till now and flagged up in the forum.
https://community.ipfire.org/t/openvpn-p12-password-on-android-problem/8127
- The problem does not occur for the .p12 file in the zip file as the downloading of the
zip file does not have the variable name in double quotes.
- Putting the zip file variable into double quotes caused the downloaded zip file to be
corrupt and not able to be opened as an archive.
- Removing the double quotes from the .p12 variable name caused the separate .p12 file
download to be able to be correctly opened.
- The same quoted variable name is used also for the cacert.pem, cert.pem, servercert.pem
and ta.key file downloads. To be consistent the same change has been applied to these.
Fixes: Bug #2883
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
