GRUB configuration update hook
by A. Wilcox
Hi all,
Alyx and I have been talking and we think GRUB should automatically
update its configuration when a new kernel is installed. Something like
triggers="grub.trigger=/usr/share/kernel"
Then grub.trigger can contain (pseudocode):
[ -f /boot/grub/grub.cfg ] || die "/boot is not mounted or GRUB is not
installed. Update the configuration manually."
[ -f /boot/grub/.manual_config ]] && die "Not overwriting your
configuration. Please update it manually before rebooting."
grub-mkconfig -o /boot/grub/grub.cfg
Thoughts?
Best,
--arw
--
A. Wilcox (awilfox)
Open-source programmer (C, C++, Python)
https://code.foxkit.us/u/awilfox/
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
1 year, 9 months
[Discussion] Default WebRTC settings for Firefox
by A. Wilcox
Hi all,
Having WebRTC enabled by default is a huge privacy loss for our users.
See [1] [2] [3] for some background.
As described in the MozillaWiki[4], there are a few different options
that we can put in our distro default config to limit this issue:
media.peerconnection.ice.no_host
This prevents Firefox from establishing outbound connections from local
addresses. This effectively disables ICE on almost all machines.
media.peerconnection.enabled
This prevents Firefox from even creating the JS objects needed for
WebRTC (it will appear as if the browser does not support ICE / STUN /
WebRTC at all). This appears to break some popular sites, like Airbnb,
per [5]. Probably too drastic.
media.peerconnection.ice.relay_only
This prevents local connections from being established, but allows
external ICE servers to function as "proxy" servers. In combination
with media.peerconnection.use_document_iceservers = false (to prevent
the document from providing its own ICE server list, which would allow
the attacker to get the information anyway), and providing a value for
media.peerconnection.default_iceservers (which would require us to find
or create a privacy-respecting ICE proxy and keep it updated), it would
allow safe use of WebRTC.
Note that this is all from quick reading and referencing of the linked
references and the Firefox source code. If anyone else can find better
or more in-depth information, that'd be great.
My personal opinion with the information presented is that we should use
media.peerconnection.ice.no_host = true. That way the objects can still
be created, but it's not possible to establish outbound connections.
Best,
--arw
[1]: https://arxiv.org/pdf/1906.10478.pdf
[2]:
https://www.ivpn.net/knowledgebase/158/My-IP-is-being-leaked-by-WebRTC-Ho...
[3]: https://github.com/diafygi/webrtc-ips - and the demo located at
https://diafygi.github.io/webrtc-ips/ which shows your IPs.
[4]: https://wiki.mozilla.org/Media/WebRTC/Privacy
[5]: https://github.com/schomery/privacy-settings/issues/55
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
1 year, 9 months
Removing old Git repositories from GitLab
by A. Wilcox
Hello all,
Now that we've migrated to the new GitLab, I think it is time we revisit
the repositories we are still keeping (in archived form):
* aports.git and aports-old.git
Both are over 100 MB and both contain nothing helpful or useful to us
any more. They're snapshots of 2017 and 2018 Alpine packages, sometimes
with improvements that made it to system/ or user/. If we want to
investigate how Alpine did something we can just look in their current
Git instead of an old mirror. I'd like to remove both of these.
* portageplus.git
This is some patches to an old version of Portage, ca early 2017, that
supports emitting APK binpkgs. It also defaults to Galapagos instead of
Gentoo as a fallback repository. (How many here even remember Galapagos?)
We can probably archive the apkkit patch for posterity and then delete
it, IMO.
* patches.git
musl compatibility patches for some packages in /etc/portage/patches format.
My suggestion is take what we haven't packaged in packages.git and save
it somewhere (or maybe just package it?), then remove it.
* etc-portage.git, apkkit-conf.git, systemsite.git
Old infrastructure from when we were a Gentoo fork. Maybe archive for
posterity, or delete it.
Comments welcome.
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
1 year, 9 months
Adelie on QEMU PPC
by BALATON Zoltan
Hello,
I'm not subscribed here (hope this still gets through), please cc me on
any reply. I'm also not sure this is the right place to send this but I
guess you may be more interested than the general QEMU crowd and could
help more with debugging the Adelie Linux side so I'm sending it here.
I'm trying to run adelie-live-ppc-1.0-beta2-20181218.iso on QEMU (mainly
to have something that's known to work on real hardware to test with).
Actually I eventually could boot it and it seems to work but I've found
some strange problems during this that I'm not sure if bug in QEMU or
guest code and how to debug it. Hope you have some idea. Here are the
details. I'm using this command with QEMU from git master as of today:
qemu-system-ppc -M mac99,via=pmu -m 1024 -boot d \
-cdrom adelie-live-ppc-1.0-beta2-20181218.iso \
-d unimp,guest_errors -serial stdio
on an x86_64 host. (This approximately emulates a PowerMac3,1 but not
exactly. I've also enabled some debug to get more details on what's
happening: #define DEBUG_EXCEPTIONS in target/ppc/excp_helper.c)
I get the grub boot menu after some errors in OF console (not sure what
are these and if could be related to the problem) then pressing enter
starts to load kernel but ends in an unexpected exception around loading
initrd that jumps off to a non-existent handler so I think this should not
happen. This is what I could find out about this:
DSI exception: DSISR=42000000 DAR=02e8d000
DSI exception: DSISR=42000000 DAR=02e8e000
^ These are last lines of loading /bzImage I think
ISI exception: msr=00003030, nip=0480afc0
ISI exception: msr=00003030, nip=0480c294
DSI exception: DSISR=40000000 DAR=04861650
^ Some grub code running?
DSI exception: DSISR=40000000 DAR=3fc5b1f4
DSI exception: DSISR=42000000 DAR=3fcc05fc
DSI exception: DSISR=40000000 DAR=3fcbed2c
DSI exception: DSISR=40000000 DAR=3fcbc974
DSI exception: DSISR=40000000 DAR=3fcba84c
DSI exception: DSISR=40000000 DAR=3fcb8f94
DSI exception: DSISR=40000000 DAR=3fcb7c78
DSI exception: DSISR=40000000 DAR=3fcb6be4
DSI exception: DSISR=40000000 DAR=3fcb5b64
DSI exception: DSISR=40000000 DAR=3fcb3a50
DSI exception: DSISR=40000000 DAR=3fcb2ffc
DSI exception: DSISR=40000000 DAR=3fca8890
DSI exception: DSISR=40000000 DAR=3fc9bffc
DSI exception: DSISR=40000000 DAR=3fcacc1c
DSI exception: DSISR=40000000 DAR=3fc5dfe0
^ Not sure what are these
ISI exception: msr=00003030, nip=048a903c
ISI exception: msr=00003030, nip=048b8fe4
ISI exception: msr=00003030, nip=048ada7c
^ More grub code
DSI exception: DSISR=42000000 DAR=00002000
ISI exception: msr=00003030, nip=048abfa4
invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 00002428 0
Invalid instruction at 00002428
and ends with the exception that should not happen and hangs here. The
interesting part is that this seems to depend on what's in the memory or
layout or positions so it may be a problem in guest code (like using an
unitialised pointer which may work if it luckily points to some data that
does not cause big harm but fails otherwise) or could also be problem in
QEMU or OpenBIOS if it does not provide something that grub expects and
this causes problem (or anything else really as I'm only guessing here).
What I've found is that when I press 'c' at the boot menu to get to grub>
prompt and then manually do:
linux /bzImage
initrd /initrd
then I get exception slightly differently, such as:
DSI exception: DSISR=42000000 DAR=02e8d000
DSI exception: DSISR=42000000 DAR=02e8e000
DSI exception: DSISR=40000000 DAR=3fde7cdc
DSI exception: DSISR=40000000 DAR=04861650
DSI exception: DSISR=42000000 DAR=3fcbaaec
DSI exception: DSISR=40000000 DAR=3fcbb2f8
DSI exception: DSISR=40000000 DAR=3fcb3a50
DSI exception: DSISR=40000000 DAR=3fcad7f8
DSI exception: DSISR=40000000 DAR=3fcae01c
DSI exception: DSISR=40000000 DAR=3fcacc1c
ISI exception: msr=00003030, nip=048a903c
ISI exception: msr=00003030, nip=048b8fe4
DSI exception: DSISR=40000000 DAR=048b0b28
ISI exception: msr=00003030, nip=048a78d8
ISI exception: msr=00003030, nip=048971e4
ISI exception: msr=00003030, nip=048981b8
DSI exception: DSISR=40000000 DAR=048afc90
ISI exception: msr=00003030, nip=048a1750
DSI exception: DSISR=40000000 DAR=8115d380
ISI exception: msr=00003030, nip=0489fc74
DSI exception: DSISR=40000000 DAR=04830520
ISI exception: msr=00003030, nip=04837e88
DSI exception: DSISR=40000000 DAR=81165080
ISI exception: msr=00003030, nip=048ada7c
DSI exception: DSISR=42000000 DAR=00002000
DSI exception: DSISR=42000000 DAR=00003000
invalid/unsupported opcode: 00 - 00 - 00 - 00 (00000000) 0000238c 0
Invalid instruction at 0000238c
So there seems to be something non-deterministic in this. I guess my first
question would be what does grub do here at nip=048ada7c? Is there a way
to guess this from the above (it's somewhere around loading initrd) or can
you make an iso with unstripped grub and if that reproduces the problem
then maybe we can get something from grub source? Where are the sources of
grub that's on the iso?
Then I've tried with my pathched OpenBIOS from here (at Known problems 1.):
http://zero.eik.bme.hu/~balaton/qemu/amiga/#morphos
which fixes a device tree problem I know about. Add
'-bios openbios-qemu.elf' to qemu command above to use it.
With that it does not get the above problem and starts to boot but seems
to get a panic (based on where it hangs) but I could not make it print
this on serial or anywhere to get more info. Do you know what options
could make the kernel log to serial during boot? I've tried earlyprintk
console=ttyPZ0 console=ttyS0 and similar but could not get output with any
of these.
But during experimenting with this sometimes I managed to boot it. Finally
I've found that if I do exactly this:
1. Use -bios openbios-qemu.elf
2. press c at boot menu to get grub> prompt
3. Type these (issue 'set' 2 times!)
grub> ls
grub> set
grub> set
grub> linux /bzImage
grub> initrd /initrd
grub> boot
then it boots. Strange! So I wonder if you have an idea how this could be
debugged and identify if it's a QEMU, OpenBIOS or guest code problem. I
think most likely could be something is missing from OpenBIOS which then
leads to using uninitialised data but without getting some debug output
from the kernel panic at least or finding out where the crash in grub is
happening I have no idea how to find what could cause this.
Thank you,
BALATON Zoltan
1 year, 10 months
system/libssh2 build failures
by Max Rees
Hello,
Not sure if this is the appropriate mailing list to do this on. But if
we want more mailing list usage, here it comes.
I just tried to reproduce the build failure of system/libssh2 on my own
machine and could not do so:
>>> libssh2: Build complete at Tue, 02 Jul 2019 19:32:18 +0000 elapsed time 0h 0m 19s
Therefore I would like to request access to larry the x86_64 builder in
order to investigate this further. Re-using my key from athena or gwyn
should be sufficient.
Max
1 year, 10 months
