From peter.mueller@link38.eu Sun Jul 1 06:49:41 2018 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH v2] embed background image in redirect template Date: Sun, 01 Jul 2018 07:49:10 +0200 Message-ID: <7cac879b-faef-ef9e-90f4-4fceec7d6c62@link38.eu> In-Reply-To: <4f21dad3b82620d4b47b59fdd4c6b90288f7d283.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4228775931353222271==" --===============4228775931353222271== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, yes, I built IPfire 2.x yesterday, and the image data were included into /srv/web/ipfire/html/redirect-templates/legacy/template.html . Is there anything wrong with this patch? Best regards, Peter M=C3=BCller > Hey, >=20 > On Sat, 2018-06-30 at 09:56 +0200, Peter M=C3=BCller wrote: >> Embed the IPFire background image into the redirect template >> directly via CSS instead of loading it from somewhere else. >> This is necessary because of Content Security Policy (CSP) and >> fixes #11650. >=20 >> This patch inserts the base64 encoded image during build so >> nothing needs to be updated twice in case background image >> changes. >=20 >> Signed-off-by: Peter M=C3=BCller >> --- >> html/html/redirect-templates/legacy/template.html | 7 ++++++- >> lfs/web-user-interface | 4 ++++ >> 2 files changed, 10 insertions(+), 1 deletion(-) >=20 >> diff --git a/html/html/redirect-templates/legacy/template.html >> b/html/html/redirect-templates/legacy/template.html >> index b5fb61ebe..297561e3a 100644 >> --- a/html/html/redirect-templates/legacy/template.html >> +++ b/html/html/redirect-templates/legacy/template.html >> @@ -3,11 +3,16 @@ >> >> > charset=3Dutf-8">=20 >> ACCESS MESSAGE >> + >> >> >> >> >> - >> >>
> align=3D"center" background=3D"/images/backgrou= nd.gif"> >> + > align=3D"center" class=3D"image"> 
>> > width=3D'80%'> >> diff --git a/lfs/web-user-interface b/lfs/web-user-interface >> index 0c5688252..b023cbd86 100644 >> --- a/lfs/web-user-interface >> +++ b/lfs/web-user-interface >> @@ -50,6 +50,10 @@ md5: >> $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) >> @$(PREBUILD) >=20 >> + # Add base64 encoded background image to Squid content access page >> + basedata=3D"$( base64 $(DIR_SRC)/html/html/images/background.gif )" >> + sed -i "s/IMAGEDATAPLACEHOLDER/${basedata}/g" >> $(DIR_SRC)/html/html/redirect-templates/legacy/template.html >=20 > Did you actually test this? >=20 >> + >> # Copy all html/cgi-bin files >> mkdir -p /srv/web/ipfire/{cgi-bin,html} >> mkdir -p /var/updatecache/{download,metadata} >=20 > -Michael >=20 --=20 "We don't care. We don't have to. We're the Phone Company." --===============4228775931353222271== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWxzNGEzQUFDZ2tRMlVqeUQzMTcKbjJqUEJBLytKQVdZRDRrUzN0 d1ozaHJrVjFYL2Y0VkZoRkMyeGcyQXByQmNhcWowV001VVdKNkVMbUM5b1p4bwpITm9Ta2c3Mmly YndjcGUzRSs3UmM1c1REQVRBSDZpbnlRc1k5RWIvMlY2b1JRYUZIZjNxV3VNbFhMMkMyV1ZIClA1 Q1FIV2w0Y3AwbDhpWVBlYk4xdjlBcTJ3VnYyUi9EelRUK3llcFByZ0VJOUtzRTRmL1VzRkErV0Y4 SzNQOXgKbWdkY2hTUGNWMmwxTWN5REdSQXEyamlhVXNkbHZRelVyMHJYN2pXS054ZGZDUHFPSVFp dFJHVEpnamJmMzU1RwpMWi9SRE80YzU5R3BielRueXN4ZTh5SEFGK1IzNUF6a085YXNRQmswamF3 QXNWTHdpVTd0b3ltakhBZlBMQkZtCmJVdEVJcEtKc25PUm9jMjMrMnRybkxNb0xMSG9kWEtOK3Jk RVZmekl6ZUVXUUNaeHlINk0wT0tEU2o1RUU5amsKM2pmUVJnN2tya1F5UDlYUUpPL2lBMmhzUzJ1 QzF3YVl4N3QvZlgxWW1qSW5aNnJyWFlISFJHR001UkU0WE9Jdwp5Mnp0L2FGNjZIckE0b2VxM2Yw UlBIbkxsNXNna1l5ZGI3NkdJdDUzRXBncVEySDNtWUl3YXNuaFVKY1RaRzBmCm0xWFo2UzMxWjJN WE05ZDNkSW5IYk5iNmQyNzFMNXljY1ByMGxOTFhlZ1doYWJCQ3JPUEZ5OHFKL2VCZ1ZNbFcKc3F6 UEZQc0tkREROUHhqcW1uQXJOYmRkdVFmS0VVU0hsVk5hRndYbGpMbUlPL2xYQVdVc3FJcjRFMEtO MXdQWQpHNUI1WVBQU0ZOcWJGaVh0VEF0SUwzV2Z2Q0N4TUF5UGlCclFVZ3FPNnhMYkozVjE4cVk9 Cj1GV05ICi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============4228775931353222271==-- From peter.mueller@link38.eu Sun Jul 1 06:51:13 2018 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: Core Update 2.12 Release Notes Date: Sun, 01 Jul 2018 07:51:11 +0200 Message-ID: <4ac3cab4-17f3-a20a-3039-f6494db2c8b3@link38.eu> In-Reply-To: <7c6507ee06948ee1e99dcc89a4693f6a4c2eba2d.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2464044465738507966==" --===============2464044465738507966== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On Wed, 2018-06-27 at 21:37 +0200, Peter M=C3=BCller wrote: >> Hello Michael, >=20 >> could you add two smaller changes to the release notes of 2.12 : >> - Firewall GUI enhancements (by Alex, make grouping of IPsec subnets possi= ble) >=20 >> - Pakfire key rollover finished >=20 > This, technically, is not finished because the server still signs all files= with > the old key. >=20 > I didn't have time yet to update the scripts. I see. Are you planning to do so before releasing the Core Update? Best regards, Peter M=C3=BCller >=20 >> Thanks, and best regards, >> Peter M=C3=BCller >=20 >> P.S.: I hopefully will have some spare time to test this at the >> weekend - along with a bunch of other things (rsyslog!). :-) >=20 --=20 "We don't care. We don't have to. We're the Phone Company." --===============2464044465738507966== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWxzNGE4OEFDZ2tRMlVqeUQzMTcKbjJpdlF3Ly9leElvalAvdEw5 YmhIR2hnMjhNMFRRYkRDbWo5M202dE1hNFZoWFFKWVE2K1pJZDhvRVdySkpjcgpxNmdHNWFrUERQ M2hWQzk0cWtDWm1scG5ibnZ4R0cxaVlzVWM2ZWcwK2I5MXJpRHBEbjdEUlptL3JLWFR5RldzClVF aDdNYzBlRmJwQmw2dzNPVzhBMlQvMFZDVHl6RHY5SzVtaWhtdXU3cW9aYXducyttL1ZyWmhSTXNW b2htZEMKOVdSMG8xS3hOWmJFRmIzWWtLRVB4NlJpWklWaXJvS2FpY3lDZlpwYTVOejg5UXJkMUV0 eUE2VEN5QlgycjVjYQpwZ0dqR1BqM21FUTVsbDAzdjVSMC90dUhoOE8zKzhhcmdVMzJqWVFlejVF VlNveE5tVjBQNzlNQ2phb2x5QmZsCmIrdVZTVEFxeEU3MUZkU0lqZVpGSFFJblJwU0o1RnRFekZ1 U1Fia1NmVzhpLzUzOThUYjQ5dExtNzV3WUJNVGQKbEcwcS9IOG1KWE5BZys2NE03d2Q3dEt3V2FP cm9QY2diN1dxNmFJc0l3eXZSTXZaQ2g2a0VIaUFSTGNEZzFkTQptbTlDUkRRSlpaQ3lEUGpKcWhB UVBGeWx3WGhvMTh0RFlVWWNzNGZoYzBkcmF2N1cxTmRwclJsQWtnbE1xRGhKCk54YXdzSWpCaUpu eldmODFod2dVeGpuL1ZXS0UzM3A2eU5aNzBuVFQ4WnBsckU3RUxUbnBBdFgreGx4cTB5bDcKcm0r bzhUdGkvWDExQUkvVnBkWUh4WWtiNi9xZkxUYUhOeCtYZ2lYeXhieCtBazAvdGxVenlZRXJsSm1G alljLwpiNXZCRVJBcGdoTXF3dnRjQnRDa2dLVlRTemt4cWtZWGZDNXFRZ0JXZmR3VGJhendLSU09 Cj1EM1pkCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============2464044465738507966==-- From peter.mueller@link38.eu Sun Jul 1 07:00:21 2018 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: In-/Outbound firewall configuration for Tor relay Date: Sun, 01 Jul 2018 08:00:17 +0200 Message-ID: <4d83263e-ca97-701e-be4e-4788bd4e482e@link38.eu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0032475305325435704==" --===============0032475305325435704== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, > On Fri, 2018-06-29 at 23:26 +0200, Peter M=C3=BCller wrote: >> Hello, >=20 >> while incoming firewall rules seem to work by now, there are still >> some issues with outgoing traffic: >=20 >> (a) Since tor runs as "nobody" (why?), allowing traffic from this >> user is out of questions because also untrusted services like Apache >> occupy this user. >=20 > Everything that is non-privileged runs as this. In IPFire 3 everything has = its > own user. Is there a technical reason why we did not split this up into several users in 2.x as well? How much work would it be to change this for 2.x too? >=20 >> (b) Filtering by PID seems the only way, but creates error messages: >=20 >> iptables v1.4.21: unknown option "--pid-owner" >> Try `iptables -h' or 'iptables --help' for more information. >=20 > Did you try the updated iptables that you submitted this week? Not yet. It might be possible that "--pid-owner" is implemented there, as it does not appear in the documentation for 1.4.x . Either way, filtering by PID has some disadvantages: (a) Every time a process changes its PID, we need to reload firewall.local. (What do we do with forks anyway?) Since PIDs may not be unique on Linux systems, some other program could obtain these network privileges. (b) The initscript of Tor needs to be patched in order to reload firewall.loc= al . During boot sequence, things are loaded the other way round, so the PID cannot be determined. A dedicated user would help here a lot. At the moment, running a relay on an ARM board in the local DMZ seems to be a more elegant way. However, on systems with any outbound connection allow= ed (which I _strongly_ advise against), this is not a pity since inbound connect= ions can be handled even by using the WebUI. Best regards, Peter M=C3=BCller >=20 >> In firewall.local, this rule is currently placed: >=20 >> iptables -A CUSTOMOUTPUT -o ppp0 -m owner --pid-owner $TORPID -p tcp -d >> 0.0.0.0/0 -j ACCEPT >=20 >> Besides from making things more easy in the future (development ;-) ), >> is "--pid-owner" even supported by iptables running here? Or does it >> require some special module? >=20 > Not that I am aware of. >=20 > -Michael >=20 >=20 >> Best regards, >> Peter M=C3=BCller >=20 >> Am 28.06.2018 um 19:14 schrieb Peter M=C3=BCller: >>> Hello Michael, >>> >>> thanks for the clarification. >>> >>>> Hello, >>>> >>>> On Wed, 2018-06-27 at 22:53 +0200, Peter M=C3=BCller wrote: >>>>> Hello, >>>>> for quite some time, IPFire includes Tor via Pakfire as an add-on. >>>>> Trying to set up a Tor relay there, I stumbled into several problems >>>>> regarding firewall rule configuration: >>>>> (a) Inbound >>>>> It turns out that Tor is not working correctly if GeoIP block is >>>>> active (this occurred after a reboot - strange). Of course, one >>>>> possibility is to disable GeoIP block at all, allow access to the >>>>> Tor relay ports, and deny any except those of legitimate countries >>>>> to other services on the firewall machine. >>>> >>>> You can use the normal firewall rules for a more granular configuration. >>>> >>>> The geoip filter comes first and then all the rest. Depending on how many >>>> countries you block here, Tor connectivity becomes a little bit useless. >>> >>> Indeed. And I block many... :-) >>>> >>>>> Since this enlarges the ruleset (already quite complex here :-| ), >>>>> I am wondering if there is a more simple way to achieve this. >>>> >>>> We could move tor rules before the GeoIP filter, but I am not sure if th= at >>>> is >>>> very intuitive. >>> >>> I do not think so since users may expect anything is blocked then and >>> wonder why Tor still works fine. We should keep firewall things intention= al >>> in order not to puzzle users. >>> >>> OK, incoming way is solved then. >>>> >>>>> (b) Outbound >>>>> For security reasons (surprise!), outgoing connections are heavily >>>>> limited here - only DNS, NTP and web traffic is allowed, and only >>>>> to a certain list of countries. Some call that "racist routing"... >>>>> This does not work with Tor since it needs to open connections to >>>>> almost any port on almost any IP address. Allowing outbound traffic >>>>> in general is out of question, so there seems to possibility left. >>>>> Besides from running a Tor relay in the local DMZ and apply the >>>>> firewall rules for this machine, is there another way? >>>> >>>> Not that I am aware of. >>>> >>>> You can build something custom here by using the -m owner module of >>>> iptables and >>>> make an exception in the OUTPUT chain for the tor process. You just need= a >>>> little script that puts the pid into it if you cannot check by uid. >>> >>> Hm, I never used the "owner" module before... >>> >>> I guess these custom firewall will need to be placed in "firewall.local" >>> (https://wiki.ipfire.org/configuration/firewall/firewall.local)? According >>> to the firewall processing scheme >>> (https://wiki.ipfire.org/_media/configuration/firewall/ipfire_fw_chains.j= pg) >>> , >>> it is processed before anything else, so this would suit. >>> >>> Will test this and get back if problems occur. >>>> >>> >>> Best regards, >>> Peter M=C3=BCller >>> >=20 >=20 >=20 --=20 "We don't care. We don't have to. We're the Phone Company." --===============0032475305325435704== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWxzNGJmRUFDZ2tRMlVqeUQzMTcKbjJoalNBLy9SR0s1TW1Dc1ox cTN0UFdwQjJFVEVsaEVPTDFYUzdmNHNqK2toQjJiWlA4SmtDb3ZGbklBQWRaVQp2WG1qMXBIQkpC ZTkrQmQ0K2QrbzU5WXVjRy9wbVNWOUd3YU9weTJqVmZDN3JFT2h1emVsVEtyZ0VPV3BXTERXCjJ1 VitUYk1WSDdlTnpIZHp4RmU5UWNZL3ZrRHNpdWF5YUJkUmdTdWE0am5YSWRublV5UHZIRFdNZXRB eVlTZDEKT0NoMkFEeVdNSTZhY3BRQTlOeGZoak5kb25KRnl3L2pZNEJObHdKRG4rT2dENVlWMnZh ZXNmRWZvNDFBU3A1WAppWVd3NUZNcEhhZGhEZzVXUWJVT1pjeFgwMnorK1VmVFpSTmVtc1VXZEQv cmNmWVd6UlgwR3hyOU1ZTWxvejBWCjd5d3c5MEE4ZVZzclhyNTdUWkZDNURlS216NG9NWCt0TUJv UTMxMDI3cXk0MUtyeGNka2h4SW5yTG1kZDhWdFkKdUQvcHZlekpiVEtMMnJtQ0xOTDg5dWpJSHNL MysvSVF1SkpjY0NJcE9lV0ZldkloZzBGOEQyY09UWGNKRHJhbQpuOW12dzY0a25TblBJeGxpdFNV SlF0anh6ZDFkWWtDWWRvUDFHdmpBYkNLN0N2OXhESkFZMk1Ed0dHemVrOExlCmV1Z2lnN2Y3Q2N5 U25Gc1VDNmI0SHRMRFlNUm1LV0N2dG5WWEQ3NkgwTGxqY0pNOXZGR0VYR1RSL2hiU04zZjMKc1Ew dExZdGN4SlRtVHVIQllMeGNabXBFOEVRR042ZFhvTkZiRGc5S3hzZmtNeUljblpUVEhGbmlGTnhw WlF4RgpZdVE0RFphKzE3Q3c2cHFaS0pCRGlRTnFJeFgxS3R0cndzbmVHMlNmRmpKbEYwWnNGbHM9 Cj03WVFQCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============0032475305325435704==-- From peter.mueller@link38.eu Sun Jul 1 07:11:04 2018 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: [PATCH] libsrtp: update to 2.2.0 Date: Sun, 01 Jul 2018 08:11:02 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7373181951778079689==" --===============7373181951778079689== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable This fixes a number of bugs and security issues. Signed-off-by: Peter M=C3=BCller --- config/rootfiles/packages/libsrtp | 49 +++++++------------------------------= -- lfs/libsrtp | 6 ++--- 2 files changed, 11 insertions(+), 44 deletions(-) diff --git a/config/rootfiles/packages/libsrtp b/config/rootfiles/packages/li= bsrtp index 3ee2e3b64..d033c34a6 100644 --- a/config/rootfiles/packages/libsrtp +++ b/config/rootfiles/packages/libsrtp @@ -1,41 +1,8 @@ -#usr/include/srtp -#usr/include/srtp/aes.h -#usr/include/srtp/aes_cbc.h -#usr/include/srtp/aes_gcm_ossl.h -#usr/include/srtp/aes_icm.h -#usr/include/srtp/aes_icm_ossl.h -#usr/include/srtp/alloc.h -#usr/include/srtp/auth.h -#usr/include/srtp/cipher.h -#usr/include/srtp/config.h -#usr/include/srtp/crypto.h -#usr/include/srtp/crypto_kernel.h -#usr/include/srtp/crypto_math.h -#usr/include/srtp/crypto_types.h -#usr/include/srtp/cryptoalg.h -#usr/include/srtp/datatypes.h -#usr/include/srtp/ekt.h -#usr/include/srtp/err.h -#usr/include/srtp/getopt_s.h -#usr/include/srtp/gf2_8.h -#usr/include/srtp/hmac.h -#usr/include/srtp/integers.h -#usr/include/srtp/kernel_compat.h -#usr/include/srtp/key.h -#usr/include/srtp/null_auth.h -#usr/include/srtp/null_cipher.h -#usr/include/srtp/prng.h -#usr/include/srtp/rand_source.h -#usr/include/srtp/rdb.h -#usr/include/srtp/rdbx.h -#usr/include/srtp/rtp.h -#usr/include/srtp/rtp_priv.h -#usr/include/srtp/sha1.h -#usr/include/srtp/srtp.h -#usr/include/srtp/srtp_priv.h -#usr/include/srtp/stat.h -#usr/include/srtp/ut_sim.h -#usr/include/srtp/xfm.h -usr/lib/libsrtp.so -usr/lib/libsrtp.so.1 -#usr/lib/pkgconfig/libsrtp.pc +#usr/include/srtp2 +#usr/include/srtp2/auth.h +#usr/include/srtp2/cipher.h +#usr/include/srtp2/crypto_types.h +#usr/include/srtp2/srtp.h +usr/lib/libsrtp2.so +usr/lib/libsrtp2.so.1 +#usr/lib/pkgconfig/libsrtp2.pc diff --git a/lfs/libsrtp b/lfs/libsrtp index d72a240ec..9fafb3606 100644 --- a/lfs/libsrtp +++ b/lfs/libsrtp @@ -24,14 +24,14 @@ =20 include Config =20 -VER =3D 1.5.4 +VER =3D 2.2.0 THISAPP =3D libsrtp-$(VER) DL_FILE =3D $(THISAPP).tar.gz DL_FROM =3D $(URL_IPFIRE) DIR_APP =3D $(DIR_SRC)/$(THISAPP) TARGET =3D $(DIR_INFO)/$(THISAPP) PROG =3D libsrtp -PAK_VER =3D 3 +PAK_VER =3D 4 =20 DEPS =3D "" =20 @@ -43,7 +43,7 @@ objects =3D $(DL_FILE) =20 $(DL_FILE) =3D $(DL_FROM)/$(DL_FILE) =20 -$(DL_FILE)_MD5 =3D 64a9580f86a9c3e1c4986e944e6a5a84 +$(DL_FILE)_MD5 =3D f77a27457d219f2991ea7aa2f0c11ec9 =20 install : $(TARGET) =20 --=20 2.16.4 --===============7373181951778079689== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRSXpCQUVCQ2dBZEZpRUV2UDRTaUdoRVlE SnlyUkxrMlVqeUQzMTduMmdGQWxzNGNIWUFDZ2tRMlVqeUQzMTcKbjJnV3pnLytNcUMwZlE2MVli aithME5nS0t6TkFsdUpUZVR0VHl0djNjTTV4b1YvV2ZJbmtvK0RWVi8rcXZRbApMTk9reFpKd3px Ujl6c0xGN3AxNWlnc2FILzU3R3dsSUY5aWJMUW5QWGx0MUZFaVVMa1VJME9yTU9aVFhBRXdWCmVi OEZIWWkySXpQNmc4Mng1S2IzaGY5bkZPZmtqVlk4QU9QZVBNSkd4OHFsbytiWGZ2cC9yam44Q3pw RzdBMGIKK3RobFkxZEFORUZobHdGSEV2Y3k2SDdYSjUrbnptU0krS3BVNER1bkhGeW1ob2czd2t0 Mk1yQTFhT0hia3MvWgovUGorY0toZ0M3YXhQcnd6VFo4dmNCNFRNRlNteEkvb0kwQ2YyWHV3MWVa UTQ5dTlVdlU3dTlVRXNkb2x0dmFNCmtWSGdTRE1UTHJ6eGFJdGJtMStnZm1OM0VlMHU5TEo2OUhI RUQ2UzBQOFR0VUpFekZaeGtxSXQ4TXBSKzl0WWkKKzZNR2l6UTh1Q2d2UE8vSEpiTy9DT0JkaXBk WmZjQXA0aHd1LzVscVR2UlRZSElvOVpnM2Y0NkNwN0N0WXAxOQpINVRFZ00ycFJkb3A0TFlyUkFM NS9JWC9jYWFUekZNQ3NnUUlwaDhINjFwaGx1MzBEMUJTczVEa05BUkk1bGpoClovdkQ4SGE1WVZ4 RE5RdUthSmhvaS9hWVpra01YOXorQzFnTytvOWdvbVExRWRqdUF4cElhNThNWkYrNEFabjAKWUg5 TThZay9kQkR2cU5lV0hlLzBJN3hXR0U2bTg1WEFHYk1rMk5WSGZJRkNrUHBLdXl2aGdOazU1clZB TmVBRApSNkhBWDY3cjBRU0s1YnRtQkhJdEZYa3lQKzRFWWZmSWhUekhsUExEV2F6RFFDQkR2b1U9 Cj1pVjg3Ci0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============7373181951778079689==-- From michael.tremer@ipfire.org Sun Jul 1 10:36:51 2018 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH v2] embed background image in redirect template Date: Sun, 01 Jul 2018 10:36:48 +0100 Message-ID: <62c066635c2dabc0643f405e3a1b22520bd4c870.camel@ipfire.org> In-Reply-To: <7cac879b-faef-ef9e-90f4-4fceec7d6c62@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2088154480027926634==" --===============2088154480027926634== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, On Sun, 2018-07-01 at 07:49 +0200, Peter M=C3=BCller wrote: > Hello Michael, >=20 > yes, I built IPfire 2.x yesterday, and the image data were included > into /srv/web/ipfire/html/redirect-templates/legacy/template.html . >=20 > Is there anything wrong with this patch? Yes, see below... > Best regards, > Peter M=C3=BCller >=20 > > Hey, > >=20 > > On Sat, 2018-06-30 at 09:56 +0200, Peter M=C3=BCller wrote: > > > Embed the IPFire background image into the redirect template > > > directly via CSS instead of loading it from somewhere else. > > > This is necessary because of Content Security Policy (CSP) and > > > fixes #11650. > > > This patch inserts the base64 encoded image during build so > > > nothing needs to be updated twice in case background image > > > changes. > > > Signed-off-by: Peter M=C3=BCller > > > --- > > > html/html/redirect-templates/legacy/template.html | 7 ++++++- > > > lfs/web-user-interface | 4 ++++ > > > 2 files changed, 10 insertions(+), 1 deletion(-) > > > diff --git a/html/html/redirect-templates/legacy/template.html > > > b/html/html/redirect-templates/legacy/template.html > > > index b5fb61ebe..297561e3a 100644 > > > --- a/html/html/redirect-templates/legacy/template.html > > > +++ b/html/html/redirect-templates/legacy/template.html > > > @@ -3,11 +3,16 @@ > > > > > > > > charset=3Dutf-8">=20 > > > ACCESS MESSAGE > > > + > > > > > > > > > > > > > > > - > > > > > >
> > align=3D"center" background=3D" > > NAME=3D"ADDRESS">/images/background.gif"> > > > + > > height=3D'152px' > > > align=3D"center" class=3D"image"> 
> > > > > width=3D'80%'> > > > diff --git a/lfs/web-user-interface b/lfs/web-user-interface > > > index 0c5688252..b023cbd86 100644 > > > --- a/lfs/web-user-interface > > > +++ b/lfs/web-user-interface > > > @@ -50,6 +50,10 @@ md5: > > > $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) > > > @$(PREBUILD) > > > + # Add base64 encoded background image to Squid content access > > > page > > > + basedata=3D"$( base64 $(DIR_SRC)/html/html/images/background.gif )" > > > + sed -i "s/IMAGEDATAPLACEHOLDER/${basedata}/g" > > > $(DIR_SRC)/html/html/redirect-templates/legacy/template.html This isn't a shell script. It is make in which every line invokes a new shell. Therefore the variable assignment happens in one shell and then the next line= in executed in a new one which knows nothing about the previous variable assignment. You will have an empty image in the result file I think. - -Michael > >=20 > > Did you actually test this? > >=20 > > > + > > > # Copy all html/cgi-bin files > > > mkdir -p /srv/web/ipfire/{cgi-bin,html} > > > mkdir -p /var/updatecache/{download,metadata} > >=20 > > -Michael > >=20 >=20 >=20 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAls4oLEACgkQgHnw/2+Q CQeJPA//TaqkNL0v9LL6IHEdI2hgHi64CjySvcDvdl3OjCw0oB5EEU5NivgI2jne Wbdlgq6GwJdZaMAUP753MQVCFznO29RSSwKxo9wlCaqMnYxmPe0f83WepWV4c7dL Fo8CplgYDdRk24wI7p68Gmexg2ZJj83IYHNTLQhqCI23WVhKtjiXQu0hRen/rreW KVoz/xqmjge2a34MhGOlbx7ZKDK0qzvpQC3ZmNgDn9BEOHHBdaxPal6b0NbyyaAu rNssQxhf5gAWGWvqCnKSf+hDgAckhpS5O6yvKp3SzlDvq2YSfVsAWSpTlAv4L/JY gGXRsd0cu9JMjLWD2gafCJ2cPHTZAYDo9Ll+NLIUi0deHTKPIsc+8XeL6U2z51qE SoWUtE0RI9Qbz80r7N/EDOVc6mIMJ1dxCQdEA2M+JDyBKyZOJRfpxG3Hf0k+JxxD N/V/u5IXxgb8CVOGQ99pPYVqI7qDVcP4eGjB49p32UxAplxg4z+d0E6JAYUjyjET uhlHUv9T/vlp8bt+GZTTyInTu/5qF5JWxeL78EIgcM868BnxI4S1Fq222P9suTy5 G9rxLK6Omf2I/YhLi9aTdjY358Qh6MUuxT0GCpr6FJFM+XnYnymsvACNM68Cji5s MNhDre+R68qb9KOcWv5kAi4lOH6sQaimzXSDalZ0QnWV1m+2ch8=3D =3D31DP -----END PGP SIGNATURE----- --===============2088154480027926634==-- From michael.tremer@ipfire.org Sun Jul 1 10:37:24 2018 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] libsrtp: update to 2.2.0 Date: Sun, 01 Jul 2018 10:37:23 +0100 Message-ID: <6c4a2c756f08971a67fa3a6f2f25846b2797c0ba.camel@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8601792143198904062==" --===============8601792143198904062== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Is asterisk compatible with the new version? - -Michael On Sun, 2018-07-01 at 08:11 +0200, Peter M=C3=BCller wrote: > This fixes a number of bugs and security issues. >=20 > Signed-off-by: Peter M=C3=BCller > --- > config/rootfiles/packages/libsrtp | 49 +++++++----------------------------= --- > - > lfs/libsrtp | 6 ++--- > 2 files changed, 11 insertions(+), 44 deletions(-) >=20 > diff --git a/config/rootfiles/packages/libsrtp > b/config/rootfiles/packages/libsrtp > index 3ee2e3b64..d033c34a6 100644 > --- a/config/rootfiles/packages/libsrtp > +++ b/config/rootfiles/packages/libsrtp > @@ -1,41 +1,8 @@ > -#usr/include/srtp > -#usr/include/srtp/aes.h > -#usr/include/srtp/aes_cbc.h > -#usr/include/srtp/aes_gcm_ossl.h > -#usr/include/srtp/aes_icm.h > -#usr/include/srtp/aes_icm_ossl.h > -#usr/include/srtp/alloc.h > -#usr/include/srtp/auth.h > -#usr/include/srtp/cipher.h > -#usr/include/srtp/config.h > -#usr/include/srtp/crypto.h > -#usr/include/srtp/crypto_kernel.h > -#usr/include/srtp/crypto_math.h > -#usr/include/srtp/crypto_types.h > -#usr/include/srtp/cryptoalg.h > -#usr/include/srtp/datatypes.h > -#usr/include/srtp/ekt.h > -#usr/include/srtp/err.h > -#usr/include/srtp/getopt_s.h > -#usr/include/srtp/gf2_8.h > -#usr/include/srtp/hmac.h > -#usr/include/srtp/integers.h > -#usr/include/srtp/kernel_compat.h > -#usr/include/srtp/key.h > -#usr/include/srtp/null_auth.h > -#usr/include/srtp/null_cipher.h > -#usr/include/srtp/prng.h > -#usr/include/srtp/rand_source.h > -#usr/include/srtp/rdb.h > -#usr/include/srtp/rdbx.h > -#usr/include/srtp/rtp.h > -#usr/include/srtp/rtp_priv.h > -#usr/include/srtp/sha1.h > -#usr/include/srtp/srtp.h > -#usr/include/srtp/srtp_priv.h > -#usr/include/srtp/stat.h > -#usr/include/srtp/ut_sim.h > -#usr/include/srtp/xfm.h > -usr/lib/libsrtp.so > -usr/lib/libsrtp.so.1 > -#usr/lib/pkgconfig/libsrtp.pc > +#usr/include/srtp2 > +#usr/include/srtp2/auth.h > +#usr/include/srtp2/cipher.h > +#usr/include/srtp2/crypto_types.h > +#usr/include/srtp2/srtp.h > +usr/lib/libsrtp2.so > +usr/lib/libsrtp2.so.1 > +#usr/lib/pkgconfig/libsrtp2.pc > diff --git a/lfs/libsrtp b/lfs/libsrtp > index d72a240ec..9fafb3606 100644 > --- a/lfs/libsrtp > +++ b/lfs/libsrtp > @@ -24,14 +24,14 @@ > =20 > include Config > =20 > -VER =3D 1.5.4 > +VER =3D 2.2.0 > THISAPP =3D libsrtp-$(VER) > DL_FILE =3D $(THISAPP).tar.gz > DL_FROM =3D $(URL_IPFIRE) > DIR_APP =3D $(DIR_SRC)/$(THISAPP) > TARGET =3D $(DIR_INFO)/$(THISAPP) > PROG =3D libsrtp > -PAK_VER =3D 3 > +PAK_VER =3D 4 > =20 > DEPS =3D "" > =20 > @@ -43,7 +43,7 @@ objects =3D $(DL_FILE) > =20 > $(DL_FILE) =3D $(DL_FROM)/$(DL_FILE) > =20 > -$(DL_FILE)_MD5 =3D 64a9580f86a9c3e1c4986e944e6a5a84 > +$(DL_FILE)_MD5 =3D f77a27457d219f2991ea7aa2f0c11ec9 > =20 > install : $(TARGET) > =20 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAls4oNMACgkQgHnw/2+Q CQfX0g//UG+4P7pOtFHIQcPFOALJrI4cCrtbwr6omHOWxCMYUIn5FXs59llCXuwW ZfsVy7GqzSWd8/yVL8TYTkM2vR2/j3HO9OCjwO7bvbyJrxTC28H32Q3laePCaPIB sVC2LKYT25nUrLi4+28NT+zzs6bt8EOuI7d4E9wliVHlZYCwhUnbPCRYWFedPTkW nLUp1OA5y2jLCjfFMDM/GS4WIYkG8fem4i2fMC98rcFvBYh2ai9smoUsMv3FAiXF upuXqmXokf3kOUvnREkFTnq8iyXFP0mP/KAjqaH+QVphzW/W3yLhKEF+UktcxfBf tbsKZieGz6ybhdA4G51VgRKmpsr/05in70uPWEMnGR9z15y6QfYIkgJMdjom0980 NOubGGFl+HESKZpGiSvEnmX+ntfykXWMjRjsmaZmewkWANQMHVXYgWGYdbDJCiz2 UYFB0eTOm0zYgs8gpkNPl3qsYtQZrjEqHs88S+ToOhxkKHdPw8u5Y1jVZ7S7rEni ptCbn+zaQB47yfFl1pN6rgp07We7F5rMEv5jmR9JyCmnE+LYO5UgEjjtdA6YVEz5 bFqCak3SL6gT43DcBN0oUt8Ivguf0SQ3BKpC+wCMNsjp3p9j/mvUR0A0CF7nrKAE DBuuwIQUUfOz3ztZZHCJyBs6OmXzXYwCHeyjTvumNQZkfnjdTAI=3D =3DQHhN -----END PGP SIGNATURE----- --===============8601792143198904062==-- From michael.tremer@ipfire.org Sun Jul 1 10:38:04 2018 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Core Update 2.12 Release Notes Date: Sun, 01 Jul 2018 10:38:03 +0100 Message-ID: <75a2f4b9f0ccdc34b949a5069590e01c361e61ea.camel@ipfire.org> In-Reply-To: <4ac3cab4-17f3-a20a-3039-f6494db2c8b3@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============9024770554610713001==" --===============9024770554610713001== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sun, 2018-07-01 at 07:51 +0200, Peter M=C3=BCller wrote: > Hello, >=20 > > On Wed, 2018-06-27 at 21:37 +0200, Peter M=C3=BCller wrote: > > > Hello Michael, > > > could you add two smaller changes to the release notes of 2.12 : > > > - Firewall GUI enhancements (by Alex, make grouping of IPsec subnets > > > possible) > > > - Pakfire key rollover finished > >=20 > > This, technically, is not finished because the server still signs all fil= es > > with > > the old key. > >=20 > > I didn't have time yet to update the scripts. >=20 > I see. Are you planning to do so before releasing the Core Update? I was, but cannot guarantee it since I have a lot of stuff going on at the moment. - -Michael >=20 > Best regards, > Peter M=C3=BCller > >=20 > > > Thanks, and best regards, > > > Peter M=C3=BCller > > > P.S.: I hopefully will have some spare time to test this at the > > > weekend - along with a bunch of other things (rsyslog!). :-) >=20 >=20 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAls4oPsACgkQgHnw/2+Q CQeHFQ//bV4e66SaqA5G65cVzow1XIgCPVLPJyX4zbPMWXImKahxurD4r31HBBEQ AXyGQOpgofrAbb6V/8YhdOVCt5lv1D0MUI0uBPmboMOtvWx9RZA9fRlzaWyP6Z4R PxtSsizW87QPY90STs0a9cofhB+YLD5/BilrhCCkyfBnUZNnYCMuC4p/XTl1U7Jo IE8Lr5jUUtqoS6kQIM5GaPe3TU0By57UgbyRkPG/UWMtshqKIYGdb8uyaUiljDNg YQ2vaSsqFrMDGPH5fj8KMkBTNuIsHiq+fFa8UgKT4HVBNWSnTj/zV7H4ML4ha9fG eDg/ObUxmQsMDSg08L9XRyYQ+fDxNonlvPYSjh2ApCX3eSuID9NE1Fg9RVGl47dz eB0DaOl5CbAdqAnUIAW+c8Dd4gZLxvQRi/yMXxitiFh2vHTqfr7MK6uMjZdrTAs8 3aKsPCn+UiNXE5cFHBioG5sZv/fnsa09bXrwS/u2JPg0xRmB3TMzZfkrEonMdDxv scNF16sJZLxNsglFh9/Pj8H8klCHqvQI7/bcNf+qrTesy3NY+3B3+jO7PxUDfoCr v4Tkg7aV7f0oiqIzukGnoGTzaiNJ7wlBnnve4P+g+CXmWoEdTP7cQcf/hNGN6h0Z P7TTXL/TtHnKIBqc3+4B1DWS/+ylfK1JWc0+ZZwmpE2mqYIJSDM=3D =3Dzlsr -----END PGP SIGNATURE----- --===============9024770554610713001==-- From michael.tremer@ipfire.org Sun Jul 1 10:39:38 2018 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: In-/Outbound firewall configuration for Tor relay Date: Sun, 01 Jul 2018 10:39:37 +0100 Message-ID: In-Reply-To: <4d83263e-ca97-701e-be4e-4788bd4e482e@link38.eu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6390085850416560495==" --===============6390085850416560495== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sun, 2018-07-01 at 08:00 +0200, Peter M=C3=BCller wrote: > Hello Michael, >=20 > > On Fri, 2018-06-29 at 23:26 +0200, Peter M=C3=BCller wrote: > > > Hello, > > > while incoming firewall rules seem to work by now, there are still > > > some issues with outgoing traffic: > > > (a) Since tor runs as "nobody" (why?), allowing traffic from this > > > user is out of questions because also untrusted services like Apache > > > occupy this user. > >=20 > > Everything that is non-privileged runs as this. In IPFire 3 everything has > > its > > own user. >=20 > Is there a technical reason why we did not split this up into several > users in 2.x as well? How much work would it be to change this for 2.x too? Yes, useradd isn't very well configured and does (or did) not support system users and all this stuff. You can give it a try. > >=20 > > > (b) Filtering by PID seems the only way, but creates error messages: > > > iptables v1.4.21: unknown option "--pid-owner" > > > Try `iptables -h' or 'iptables --help' for more information. > >=20 > > Did you try the updated iptables that you submitted this week? >=20 > Not yet. It might be possible that "--pid-owner" is implemented there, > as it does not appear in the documentation for 1.4.x . >=20 > Either way, filtering by PID has some disadvantages: > (a) Every time a process changes its PID, we need to reload firewall.local. > (What do we do with forks anyway?) Since PIDs may not be unique on Linux > systems, some other program could obtain these network privileges. >=20 > (b) The initscript of Tor needs to be patched in order to reload > firewall.local . > During boot sequence, things are loaded the other way round, so the PID > cannot be determined. A dedicated user would help here a lot. Agreed. > At the moment, running a relay on an ARM board in the local DMZ seems to > be a more elegant way. However, on systems with any outbound connection > allowed > (which I _strongly_ advise against), this is not a pity since inbound > connections > can be handled even by using the WebUI. >=20 > Best regards, > Peter M=C3=BCller > >=20 > > > In firewall.local, this rule is currently placed: > > > iptables -A CUSTOMOUTPUT -o ppp0 -m owner --pid-owner $TORPID -p tcp -d > > > 0.0.0.0/0 -j ACCEPT > > > Besides from making things more easy in the future (development ;-) ), > > > is "--pid-owner" even supported by iptables running here? Or does it > > > require some special module? > >=20 > > Not that I am aware of. > >=20 > > -Michael > >=20 > >=20 > > > Best regards, > > > Peter M=C3=BCller > > > Am 28.06.2018 um 19:14 schrieb Peter M=C3=BCller: > > > > Hello Michael, > > > >=20 > > > > thanks for the clarification. > > > >=20 > > > > > Hello, > > > > >=20 > > > > > On Wed, 2018-06-27 at 22:53 +0200, Peter M=C3=BCller wrote: > > > > > > Hello, > > > > > > for quite some time, IPFire includes Tor via Pakfire as an add-on. > > > > > > Trying to set up a Tor relay there, I stumbled into several probl= ems > > > > > > regarding firewall rule configuration: > > > > > > (a) Inbound > > > > > > It turns out that Tor is not working correctly if GeoIP block is > > > > > > active (this occurred after a reboot - strange). Of course, one > > > > > > possibility is to disable GeoIP block at all, allow access to the > > > > > > Tor relay ports, and deny any except those of legitimate countries > > > > > > to other services on the firewall machine. > > > > >=20 > > > > > You can use the normal firewall rules for a more granular > > > > > configuration. > > > > >=20 > > > > > The geoip filter comes first and then all the rest. Depending on how > > > > > many > > > > > countries you block here, Tor connectivity becomes a little bit > > > > > useless. > > > >=20 > > > > Indeed. And I block many... :-) > > > > >=20 > > > > > > Since this enlarges the ruleset (already quite complex here :-| ), > > > > > > I am wondering if there is a more simple way to achieve this. > > > > >=20 > > > > > We could move tor rules before the GeoIP filter, but I am not sure = if > > > > > that > > > > > is > > > > > very intuitive. > > > >=20 > > > > I do not think so since users may expect anything is blocked then and > > > > wonder why Tor still works fine. We should keep firewall things > > > > intentional > > > > in order not to puzzle users. > > > >=20 > > > > OK, incoming way is solved then. > > > > >=20 > > > > > > (b) Outbound > > > > > > For security reasons (surprise!), outgoing connections are heavily > > > > > > limited here - only DNS, NTP and web traffic is allowed, and only > > > > > > to a certain list of countries. Some call that "racist routing"... > > > > > > This does not work with Tor since it needs to open connections to > > > > > > almost any port on almost any IP address. Allowing outbound traff= ic > > > > > > in general is out of question, so there seems to possibility left. > > > > > > Besides from running a Tor relay in the local DMZ and apply the > > > > > > firewall rules for this machine, is there another way? > > > > >=20 > > > > > Not that I am aware of. > > > > >=20 > > > > > You can build something custom here by using the -m owner module of > > > > > iptables and > > > > > make an exception in the OUTPUT chain for the tor process. You just > > > > > need a > > > > > little script that puts the pid into it if you cannot check by uid. > > > >=20 > > > > Hm, I never used the "owner" module before... > > > >=20 > > > > I guess these custom firewall will need to be placed in "firewall.loc= al" > > > > (https://wiki.ipfire.org/configuration/firewall/firewall.local)? > > > > According > > > > to the firewall processing scheme > > > > (https://wiki.ipfire.org/_media/configuration/firewall/ipfire_fw_chai= ns. > > > > jpg) > > > > , > > > > it is processed before anything else, so this would suit. > > > >=20 > > > > Will test this and get back if problems occur. > > > > >=20 > > > >=20 > > > > Best regards, > > > > Peter M=C3=BCller > > > >=20 > >=20 > >=20 > >=20 >=20 >=20 -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAls4oVkACgkQgHnw/2+Q CQf5KxAAg270VjY7AG/yiV8O8auIVePrpaQ74EfbpYIRUHBWH7uPqF7Ag4TB40Ho CCqdP6mowePfTjmgM6UDU9vry3Pu0hh/L+gKHtw3cNh2TZJGfNDjeCvcG+kMV8oA j945kk1awse34XDgiJh8wpemvNzpIqKIRJFJvo8VdKhI6d1IeIgA3VWhJjv/31lU cl8J4WJW9dVy750eM7oHRMxE6RY8TvDnQHP1CYCRBwwH21jN9rHyIU55zJbCkm6N i4acEyUD6IiYUslHEudp6Sa5UzCrSnuVb/cNn3xUnjmwUyRfTJkXg1ypWgn/IV9N PTg+G/QkNYrC2CH2LtIKnTguTF026OZzCfAhkpoLdUsdNG/W4R/1iANr6QzuDZz7 4jHi6F6ujEontoRKecXxIq0lbv21bHM8kKGS8lXDUZSafX9ku0ALzRCCJcvMygOJ k3RN3iyMQg5PEIDJ9sOt8eBoYS22TNTYbgJShesI+WR9srv2pNWjdM8q7gXC4UmU Giu4//MN2R/f5R0WpSPzTzEved01j+cGcKSDacAdRwACNlRXY3utNE0MCKF4KXo5 NmUmbM+XFIpAP5qGjvpa65tHfOeI9rZAIjdbVsd0RNEuhwVrKENfKN09pt6Pz87Z sPciMueAK056cAPrJd63HIoUxaxIVPpEyvqk5tiSCUFagB8YtEQ=3D =3D17qc -----END PGP SIGNATURE----- --===============6390085850416560495==-- From peter.mueller@link38.eu Sun Jul 1 12:45:43 2018 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: [PATCH v2] embed background image in redirect template Date: Sun, 01 Jul 2018 13:45:32 +0200 Message-ID: In-Reply-To: <62c066635c2dabc0643f405e3a1b22520bd4c870.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6902841613735296234==" --===============6902841613735296234== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, > Hi, >=20 > On Sun, 2018-07-01 at 07:49 +0200, Peter M=C3=BCller wrote: >> Hello Michael, >=20 >> yes, I built IPfire 2.x yesterday, and the image data were included >> into /srv/web/ipfire/html/redirect-templates/legacy/template.html . >=20 >> Is there anything wrong with this patch? >=20 > Yes, see below... >=20 >> Best regards, >> Peter M=C3=BCller >=20 >>> Hey, >>> >>> On Sat, 2018-06-30 at 09:56 +0200, Peter M=C3=BCller wrote: >>>> Embed the IPFire background image into the redirect template >>>> directly via CSS instead of loading it from somewhere else. >>>> This is necessary because of Content Security Policy (CSP) and >>>> fixes #11650. >>>> This patch inserts the base64 encoded image during build so >>>> nothing needs to be updated twice in case background image >>>> changes. >>>> Signed-off-by: Peter M=C3=BCller >>>> --- >>>> html/html/redirect-templates/legacy/template.html | 7 ++++++- >>>> lfs/web-user-interface | 4 ++++ >>>> 2 files changed, 10 insertions(+), 1 deletion(-) >>>> diff --git a/html/html/redirect-templates/legacy/template.html >>>> b/html/html/redirect-templates/legacy/template.html >>>> index b5fb61ebe..297561e3a 100644 >>>> --- a/html/html/redirect-templates/legacy/template.html >>>> +++ b/html/html/redirect-templates/legacy/template.html >>>> @@ -3,11 +3,16 @@ >>>> >>>> >>> charset=3Dutf-8">=20 >>>> ACCESS MESSAGE >>>> + >>>> >>>> >>>> >>>> >>>> - >>>> >>>>
>>> align=3D"center" background=3D">>> NAME=3D"ADDRESS">/images/background.gif"> >>>> + >>> height=3D'152px' >>>> align=3D"center" class=3D"image"> 
>>>> >>> width=3D'80%'> >>>> diff --git a/lfs/web-user-interface b/lfs/web-user-interface >>>> index 0c5688252..b023cbd86 100644 >>>> --- a/lfs/web-user-interface >>>> +++ b/lfs/web-user-interface >>>> @@ -50,6 +50,10 @@ md5: >>>> $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) >>>> @$(PREBUILD) >>>> + # Add base64 encoded background image to Squid content access >>>> page >>>> + basedata=3D"$( base64 $(DIR_SRC)/html/html/images/background.gif )" >>>> + sed -i "s/IMAGEDATAPLACEHOLDER/${basedata}/g" >>>> $(DIR_SRC)/html/html/redirect-templates/legacy/template.html >=20 > This isn't a shell script. It is make in which every line invokes a new she= ll. > Therefore the variable assignment happens in one shell and then the next li= ne in > executed in a new one which knows nothing about the previous variable > assignment. This sounds correct. However, in case I ran "./make.sh build", there actually is some image data in the built file: ~> cat ~/devel/ipfire-2.x/build/srv/web/ipfire/html/redirect-templates/legacy= /template.html | head -n 8 =20 ACCESS MESSAGE > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > > > > > > >
> > > > height=3D'130' > > > > > align=3D"center" background=3D" > > > > NAME=3D"ADDRESS">/images/background.gif"> > > > > > + > > > > height=3D'152px' > > > > > align=3D"center" class=3D"image"> 
> > > > > > > > > bgcolor=3D'#CC000000' > > > > > width=3D'80%'> > > > > > diff --git a/lfs/web-user-interface b/lfs/web-user-interface > > > > > index 0c5688252..b023cbd86 100644 > > > > > --- a/lfs/web-user-interface > > > > > +++ b/lfs/web-user-interface > > > > > @@ -50,6 +50,10 @@ md5: > > > > > $(TARGET) : $(patsubst %,$(DIR_DL)/%,$(objects)) > > > > > @$(PREBUILD) > > > > > + # Add base64 encoded background image to Squid content access > > > > > page > > > > > + basedata=3D"$( base64 > > > > > $(DIR_SRC)/html/html/images/background.gif )" > > > > > + sed -i "s/IMAGEDATAPLACEHOLDER/${basedata}/g" > > > > > $(DIR_SRC)/html/html/redirect-templates/legacy/template.html > >=20 > > This isn't a shell script. It is make in which every line invokes a new > > shell. > > Therefore the variable assignment happens in one shell and then the next > > line in > > executed in a new one which knows nothing about the previous variable > > assignment. >=20 > This sounds correct. However, in case I ran "./make.sh build", there actual= ly > is some image data in the built file: >=20 > ~> cat ~/devel/ipfire-2.x/build/srv/web/ipfire/html/redirect- > templates/legacy/template.html | head -n 8 > > > > 8">=20 > ACCESS MESSAGE >