This is really badly hacky, but I do not know a better way to solve this
with our existing "setup" program which would be a nightmare to extend.
So we are using the device number to generate a static MAC address which
can then be used as usual. I doubt many people will have more than one
device.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
When acquiring an IP address, dhcpcd seems to think that the interface
is down or does not work properly for some reason. It will
subsequentially decide to exit which is not what we want here.
Therefore this patch tells dhcpcd to ignore the link state and keep
happily running.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This could potentially create problems when we abuse these functions to
launch the DHCP client on IPTV interfaces. This would have to be tested
and confirmed or potentially we would need some more changes to keep
supporting that use-case, too.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This has been removed a long time ago and we should probably spend a
little bit more time on keeping the networking code tidy :)
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
QMI is a proprietary interface from Qualcomm which are absolute pioneers
when it comes to interfacing with modems. I don't think there would be
any way to make this any more complicated and bloated.
So, bascially we will put the modem into a raw IP mode which changes the
interface into Point-to-Point mode.
We then configure the provider settings using qmicli. After that, the
modem will try to connect to the provider and obtain an IP address.
We will then start a DHCP client which does not do any DHCP-ing because
implementing that would be too complicated. Instead we do something even
*more* complicated where we would launch a custom script which asks the
modem for the allocated IP address and will configure it into the
device. The DHCP client then reads that IP address from the device and
pretends it came up with it by itself. Such an easy way to do this.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This ensures restoring a backup won't silently bring back an insecure
Diffie-Hellman parameter (which could also not be inspected through the
web interface anymore).
Reported-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Full changelog:
Changes in version 0.4.7.12 - 2022-12-06
This version contains a major change that is a new key for moria1. Also, new
metrics are exported on the MetricsPort for the congestion control
subsystem.
o Directory authority changes (moria1):
- Rotate the relay identity key and v3 identity key for moria1. They
have been online for more than a decade and refreshing keys
periodically is good practice. Advertise new ports too, to avoid
confusion. Closes ticket 40722.
o Minor feature (Congestion control metrics):
- Add additional metricsport relay metrics for congestion control.
Closes ticket 40724.
o Minor features (fallbackdir):
- Regenerate fallback directories generated on December 06, 2022.
o Minor features (geoip data):
- Update the geoip files to match the IPFire Location Database, as
retrieved on 2022/12/06.
o Minor bugfixes (cpuworker, relay):
- Fix an off by one overload calculation on the number of CPUs being
used by our thread pool. Fixes bug 40719; bugfix on 0.3.5.1-alpha.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
This patch will gracefully terminate the daemon when it loses its
connection to the OpenVPN daemon.
Fixes: #12963
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
- On CU172 Testing Build: master/eb9e29f9 when selecting the OpenVPN menu it showed the
Diffie-Hellman info and pressing back took you to the same DH page.
- Tested patch suggestion from Erik on vm testbed and confirmed that it worked.
Suggested-by: Erik Kapfer <erik.kapfer@ipfire.org>
Tested-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Again, xz currently present on an IPFire machine is linked
against this. Thus, deleting this file causes the unpack
routine to fail, which is why we should have never deleted
it in the first place.
Reported-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
On November 30, 2022, Mozilla decided to take the following
actions as a response to the concerns raised about the merits
of this root CA operator (excerpt taken from
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4/m/yLohoVqtCgAJ):
> 1. Set "Distrust for TLS After Date" and "Distrust for S/MIME
> After Date" to November 30, 2022, for the 3 TrustCor root
> certificates (TrustCor RootCert CA-1, TrustCor ECA-1,
> TrustCor RootCert CA-2) that are currently included in
> Mozilla's root store.
>
> 2. Remove those root certificates from Mozilla's root store
> after the existing end-entity TLS certificates have expired.
As far as the latter is concerned, the offending certificates
have these expiry dates set:
- TrustCor RootCert CA-1: Mon, 31 Dec 2029 17:23:16 GMT
- TrustCor RootCert CA-2: Sun, 31 Dec 2034 17:26:39 GMT
- TrustCor ECA-1: Mon, 31 Dec 2029 17:28:07 GMT
The way IPFire 2 currently processes Mozilla's trust store
does not feature a way of incorporate a "Distrust for XYZ After
Date" attribute. This means that despite TrustCor Systems root
CAs are no longer trusted by browsers using Mozilla's trust
store, IPFire would still accept certificates directly or
indirectly issued by this CA until December 2029 or December 2034.
To protect IPFire users, this patch therefore suggests to
patch our copy of Mozilla's trust store in order to remove
TrustCor Systems' root CAs: The vast majority of HTTPS connections
established from an IPFire machine take place in a non-interactive
context, so there is no security benefit from a "Distrust After
Date" information. Instead, if we do not want IPFire installations
to trust this CA, we have no other option other than remove it
unilaterally from our copy of Mozilla's trust store.
See also: https://lists.ipfire.org/pipermail/development/2022-November/014681.html
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
