The officially official Devuan Forum!

You are not logged in.

#76 Re: Installation » How is it possible that Java update breaks Trinity DE? » 2021-01-10 01:34:03

apt-get install libbcmail-java libbcpkix-java libbcprov-java libservlet3.1-java openjdk-8-jdk openjdk-8-jdk-headless openjdk-8-jre openjdk-8-jre-headless -t=ascii-backports
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Suggested packages:
  libbcmail-java-doc libbcpkix-java-doc libbcprov-java-doc openjdk-8-demo openjdk-8-source visualvm icedtea-8-plugin fonts-indic
The following packages will be upgraded:
  libbcmail-java libbcpkix-java libbcprov-java libservlet3.1-java openjdk-8-jdk openjdk-8-jdk-headless openjdk-8-jre openjdk-8-jre-headless
8 upgraded, 0 newly installed, 0 to remove and 150 not upgraded.
Need to get 0 B/43.1 MB of archives.
After this operation, 105 kB of additional disk space will be used.

There is nothing except java in the actually upgraded list and still though it breaks Trinity somehow.

I am now after zfs rollback to a savepoint before trying to upgrade java.

apt-get dist-upgrade -t=ascii-backports

does the same break of the Trinity.

#77 Installation » How is it possible that Java update breaks Trinity DE? » 2021-01-09 22:44:41

bimon
Replies: 29

After running following command:

apt-get install libbcmail-java libbcpkix-java libbcprov-java libservlet3.1-java openjdk-8-jdk openjdk-8-jdk-headless openjdk-8-jre openjdk-8-jre-headless -t=ascii-backports

After that TDM does not start anymore, its log:

Jan 10 01:32:35 tdm_config[8368] info: Cannot open master configuration file /etc/trinity/tdm/tdmdistrc

X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.19.0-13-amd64 x86_64 Debian
Current Operating System: Linux workstation
Build Date: 09 December 2020  10:09:47AM
xorg-server 2:1.19.2-1+deb9u7 (https://www.debian.org/support) 
Current version of pixman: 0.34.0
        Before reporting problems, check http://wiki.x.org
        to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Sun Jan 10 01:32:35 2021
(==) Using system config directory "/usr/share/X11/xorg.conf.d"
/opt/trinity/bin/tdm_greet: error while loading shared libraries: libtderandr.so.0: cannot open shared object file: No such file or directory
Jan 10 01:32:35 tdm: :0[8388] error: Abnormal termination of greeter for display :0, code 127, signal 0
(II) Server terminated successfully (0). Closing log file.

Trying to upgrade Trinity to 14.0.9 and 14.0.10 does NOT help at all, I get the same error with newer versions.

#78 Re: Devuan » Archiving Devuan repositories » 2020-10-23 23:45:23

Hello,

Earlier I specified the components explicitelly like:

Components="main contrib non-free"; 

Now I have made following new config for aptly which includes all components by default without specifying them explicitly :

#aptly mirror show devuan-ascii                                                                                                                                                                    

Name: devuan-ascii                                                                                                                                                                                                                          
Archive Root URL: https://pkgmaster.devuan.org/merged/                                                                                                                                                                                           
Distribution: ascii                                                                                                                                                                                                                              
Components: main, contrib, non-free, raspi, beaglebone, droid4, n900, n950, n9, sunxi, exynos                                                                                                                                                     
Architectures: i386, amd64, armhf                                                                                                                                                                                                                 
Download Sources: yes                                                                                                                                                                                                                             
Download .udebs: no                                                                                                                                                                                                                               
Last update: never                                                                                                                                                                                                                                                             
                                                                                                                                                                                                                                                                               
Information from release file:                                                                                                                                                                                                                                                 
Architectures: amd64 arm64 armel armhf i386 ppc64el                                                                                                                                                                                                                            
Codename: ascii                                                                                                                                                                                                                                                                
Components: main contrib non-free raspi beaglebone droid4 n900 n950 n9 sunxi exynos                                                                                                                                                                                            
Date: Fri, 23 Oct 2020 03:30:13 UTC                                                                                                                                                                                                                                            
Label: Devuan                                                                                                                                                                                                                                                                  
Origin: Devuan                                                                                                                                                                                                                                                                 
Suite: oldstable                                                                                                                                                                                                                                                               
Valid-Until: Fri, 30 Oct 2020 03:27:17 UTC
Version: 2.1

And after running aptly update I get an error about missing components except general ones: main contrib non-free:

Downloading https://pkgmaster.devuan.org/merged/dists/ascii/InRelease...
gpgv: Signature made Thu 22 Oct 2020 11:30:13 PM EDT using RSA key ID 61FC752C
gpgv: Good signature from "Devuan Repository (Amprolla3 on Nemesis) <repository@devuan.org>"
Downloading & parsing package files...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/main/binary-i386/Packages.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/main/binary-amd64/Packages.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/main/binary-armhf/Packages.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/main/source/Sources.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/contrib/binary-i386/Packages.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/contrib/binary-amd64/Packages.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/contrib/binary-armhf/Packages.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/contrib/source/Sources.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/non-free/binary-i386/Packages.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/non-free/binary-amd64/Packages.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/non-free/binary-armhf/Packages.gz...
Downloading https://pkgmaster.devuan.org/merged/dists/ascii/non-free/source/Sources.gz...
ERROR: unable to update: no candidates for https://pkgmaster.devuan.org/merged/dists/ascii/raspi/binary-i386/Packages found

How shall this be handled? Why there are more board specific components and they do not work in aptly anyway?

What is the purpose of the components: raspi beaglebone droid4 n900 n950 n9 sunxi exynos ?
What do I miss if not including them into my archive?

#79 Re: Devuan » Archiving Devuan repositories » 2020-10-22 00:21:47

For now I prefer to try aptly tool for repo mirroring, it looks very convenient to me.

Why architecture "all" (common for all CPUs, generally just scripts) mentioned on the page:
https://www.debian.org/mirror/size
is not available?

aptly -architectures="all" mirror create devuan-all-ascii https://pkgmaster.devuan.org/merged/  ascii main contrib non-free

Downloading https://pkgmaster.devuan.org/merged/dists/ascii/InRelease...
gpgv: Signature made Wed 21 Oct 2020 07:59:30 PM EDT using RSA key ID 61FC752C
gpgv: Good signature from "Devuan Repository (Amprolla3 on Nemesis) <repository@devuan.org>"
ERROR: unable to fetch mirror: architecture all not available in repo [devuan-all-ascii]: https://pkgmaster.devuan.org/merged/ ascii, use -force-architectures to override

An example of a package:
https://packages.debian.org/buster/all/firehol/download

#80 Re: Devuan » Archiving Devuan repositories » 2020-10-19 04:51:34

I guess aptly is the most convenient tool for the task?

Just: apt-get install aptly
And then:

aptly -architectures="amd64" mirror create devuan-amd64-ascii https://pkgmaster.devuan.org/merged/  ascii main contrib non-free
aptly mirror update devuan-amd64-ascii

then the same repeated also for the following repos: ascii-backports, ascii-proposed-updates, ascii-security, ascii-updates

Is it enough to have a good full and exhaustive offline archive of the Devuan ASCII 64bit?
I have found Devuan ASCII super rock solid and stable and would not like to upgrade it in a few years.
I would like to have all ASCII deb files available for me even after your next Chimaera release is ready, ASCII will become oldoldstable like Jessie is now.

I can use any needed new software in KVM virtual machines with Devuan Beowulf and Chimaera, Alpine Edge, etc. and would like to keep ASCII on the host and enjoy its stability.

And I wonder, what I get if downloading the whole:
https://pkgmaster.devuan.org/merged/pool/DEVUAN/
?
Does it have all Devuan specific packages which are not present in Debian?

#81 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-10-10 03:34:38

Btw, Nitrokey HSM2 USB token and a flat SC-HSM2 4K smart card both implement a data channel encryption (between your PC PKCS11 lib and their crypto chip) via BSI TR-03110 protocol also used in some national personal ID cards. May be it just is so called protection from attacks on emanation side channel.

bimon wrote:

Another standalone computer (AMD about 2010 model) with a modern HGST 6TB HUS drive was controlled remotely and replaced some of video surveillance files into a binary rubish, and it had ZFS, it means HDD most likely has a backdoor for remote wireless control and its Linux drivers have an interface to bypass control into the kernel and may be some userspace.

Actually it may be a wired (not wireless as I mentioned earlier) backdoor, IMHO the most probable channel for remote control is an AC power line, a signal can be modulated somehow and some modern devices with a powerful enough MCUs or SoCs for example like modern HDDs can have corresponding modems to phone via AC line in an active mode, not like a relatively safe for us good old passive readonly TEMPEST known earlier.

#83 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-08-20 02:40:50

chris2be8 wrote:

But if you do need to keep secrets:
1: The safest option is to keep it all in your head. If you must share information talk face to face and make sure there are no listening devices around.

2: Use pencil (or pen) and paper. Mass surveilance of mail is too much work for the authorities (at least in civilised countries). If you must use a computer use one that's not connected to the internet (check for wireless adapters etc). This is standard for tax advisers etc (not illegal but laws can be changed to your disadvantage if they know what you are planning).

3: If you have to use the internet then use normal computer security procedures. And keep anything really sensitive off the system.

Chris

1. Two very important channels for data leakage often not taken into account are:
1.1 Electromagnetic emanation from all computer buses (like SATA, USB, Ethernet, PS2, VGA, HDMI, etc.)
1.2 Psi operators can read your mind (your current thoughts and may be even memory) distantly, predict some future and try to correct it in their favor.

Though these two channels are not directly related to each other they are often used by some agencies together at the same time.
So you shall never use passwords as they can be intercepted both from computer bus and your head without any visible connection like LAN, etc.
Always try to use keys which are not stored on devices like HDDs or SSDs. For example Nitrokey company states HSM2 is protected from data leakage by emanation channel (but at which grade? a few layers of tin foil?), though there may be other backdoors in Nitrokey of course. Even their crypto algorithms most likely are not strong enough against NSA and may be other agencies too.
May be GNUK (or Nitrokey Start) sometimes can be better in terms of its open source, I do not know unfortunately.

2,3. My computers were attacked by electromagnetic attacks too, it does not matter if Internet is connected or not.

https://web.archive.org/web/20191105180 … ssues/9518

Also a standalone (without Internet and even without LAN connection) relatively old computer (Intel about 2002 model)  which was almost always turned off at my home was reflashed somehow and did not boot into Linux until I reflashed it again back to a stock BIOS from a floppy.

Another standalone computer (AMD about 2010 model) with a modern HGST 6TB HUS drive was controlled remotely and replaced some of video surveillance files into a binary rubish, and it had ZFS, it means HDD most likely has a backdoor for remote wireless control and its Linux drivers have an interface to bypass control into the kernel and may be some userspace.

#84 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-08-20 02:22:29

chris2be8 wrote:

Hello bimon,

The staphylococcus poisoning was probably an accident. It's impossible to say exactly what effect it would have on any given individual. So it's not any use to control someone.

Hello Chris,

The accident happened only to me, not to my classmate who was eating at the same place (the same small table) and he was brought his meal too by a staff and it looked on the surface the same as mine.

The effects of poisoning by golden staphylococcus are predictable: persistent meteorism, bad microflora and as a consequence a bad immune resistance,  insomnia, dermatosis and bad blood reaction on meds used for handling of dermatosis.

The whole effect is a gain for ganstalkers, a person becomes more vulnerable to their attacks (including load sounds at night, anonymous calls, etc.), harder life, personal problems, difficult to work productively because of regular insomnia.

#85 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-08-19 18:06:47

freenet_bro wrote:

I have three Raspberry Pis, but not the necessary connectors.

Raspberry Pis could not even start without large BLOBs for video chip.

The best what I was able to find are AllWinner Cortex A7 and Beagle Bone Black boards.
They are affordable and can work (at least in a text mode) without BLOBs except their small BROM inside their SoC.

IMHO even librebooted X86 is not good as a secure SSH terminal to control other hosts, they can be used only to host something non critical in terms of security.

I do not know anything affordable for a secure trusted terminal better than an old ARM Cortex A7 free from BLOBs and wireless chips with a Nitrokey or may be GNUK for keeping your secret keys there.

Btw, there is an interesting ARM laptop trying to be as free as possible (not Cortex A7 though):

https://web.archive.org/web/20200828204 … _Main_Page
https://www.bunniestudios.com/blog/?cat=28

#86 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-08-19 17:49:16

For now please write here, may be later when I have a better anonymization like I2P+Tor router we can chat sometimes in a Tox or Jabber.

#87 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-08-19 10:22:13

Very probable that I was poisoned by a significant portion of staphylococcus (diagnosed later by analysis) during training courses for IBM DB2 administration in a "Network Academy" located in a building of their police academy located in Kazan, Russia on October 13, 2008 in their dining-hall, they brought a meal by themselves. During all night in their hotel I experienced continuous almost non uninterruptible meteorism, there is a eye-witness classmate, we had even to open window inspite of almost winter weather, I never used to eat in their dining-hall anymore and got food in supermarkets during the rest of training days.
When we had meeting with other classmates from different cities in the evening they talked about terror from FSB in their cities like fires and pressure, women mentioned very bad quality of doctor service in maternity hospital and how they got even disability after accouchement and could not sue the doctors in a court.
Also I felt myself sick like in a winter like getting a flue virus, gravedo and feeling very weak, it is an indication of an attack on immune system.
Later when I returned to my city large dark-red sometimes almost black pustules appeared on my head and body for many years and a few still now, during many years I experienced significant headaches. Doctors could not find a course when I asked them earlier.
I had to part with my lovely girlfriend in about two years since that DB2 training sad

ee429cb3d2034a344fdfefc0b0302108.png

And finally in 2017 I was diagnosed a polycythemia.
After I wrote several times about corruption in Russia my body experienced burning pain and vibration, my mother too (she experienced it even today after this post asking me for a tablet of aspirin), several neurologists  led me to a psychiatrists, they did not do anything to help me except harm in their clinic where I even did not get enough air to breath (a body with blood problems requires more oxygen for living) , persistent  constipation problems during a whole month period of being in their clinic when I repeatedly could not get defecation up to five days even visiting toilet room tens of times and it is even not always allowed by personal to travel to that room, btw. And it was very hard to convince them to purchase and give me laxative, without it most likely I would already be dead.   After leaving their clinic all symptoms returned in about two weeks like body burning and vibration.

Later I have found a med by myself to heal myself successfully from vibration and burning, it is neuromedin and human interferon alfa, blood returned to a relatively good condition too, I do not have an insomnia or headaches anymore except days when I do a med injection.

After that I often treat doctors (I visited tens of them before getting to psychiatrists) like charlatans just serving ZOG and agencies to make tortures against targeted individuals, they are almost like fascist in their activity against targeted individuals.

It works something like following:

navyazchivaya-ideya_83527.jpg

#88 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-08-19 06:55:20

And as for defending from BLOBs in storage controllers someone already discussed that in the topics like:

http://dev1galaxy.org/viewtopic.php?pid=17208#p17208
http://dev1galaxy.org/viewtopic.php?pid=16484#p16484

And unfortunately there are no affordable RISC-V having at least 1-2GB or RAM comparable to many cheap Cortex A7 boards like OrangePI some of which are even compatible with OpenBSD.

May be some MIPS like Octeons can be interesting for running OpenBSD on them too.

Do we really have any affordable choices even already in 2020 year for a hardware more secure than X86 with at least 1-2 GB of RAM except ARM Cortex A7 and MIPS?

And I would not trust even to the same Cortex A7 chips produced recently compared to older ones from a second hand market. I have already experienced several bad recent simple SATA controllers which destroyed a half of my ZFS mirrors (recoved later of course), recent chips compatible with earlier specifications look different in some cases under attacks and behave like a beasty. Most likely they have more recent backdoors in hardware and firmware. So the older BROM and SoC are the better it is in terms of resistance to ganstalker attacks.

And never trust intelligent agencies, they almost always lie just to make some profit from their public declarations, they inject many their backdoors everywhere they can to control everything and even make criminal harm to law-abiding citizens in favor of corporations who sponsor them. The same about trust to some doctors and lawers, there is a significant amount of those "specialists" who lie to you just to support the whole corrupted construction and make a harm to  individuals targeted by agencies. Sometimes even police behave the same way.

If you a targeted individual then try to never eat anything except what you get by yourself from a supermarket choosen randomly because ganstalkers sometimes use to poison people with a slowly influencing bio substances like staphylococcus which in a long term together with their electromagnetic attacks may lead to decrease of immunoresistance of your body,  dermatosis, bad reactions to the meds used and even to small mutations like a chronical blood mutations like leucosis and insomnia. They even may use mind control of your oldery relatives to make them behave like mads, often disturbing you in the most critical moments of your life for example during your sleep, trying to feed you with a food they got from unknown sources, such unverified food they were often received for free from someones may contain psychotic stuff to make you temporary mad too.

And then ganstalkers tell, you need to go to a psychiatrist, their win - congratulations! And you get a bad reputation finally.

A few of examples:
https://web.archive.org/web/20190624163 … duals.html
https://web.archive.org/web/20200314022 … cults.com/
http://www.freezepage.com/1562758630UEPBNMQAJI
https://web.archive.org/web/20190610035 … BJJVVBJ/64
https://archive.is/1ipek
https://web.archive.org/web/20190608024 … ad/1348072

I think more anonymization for key developers of Devuan and OpenBSD would not be bad for them and all of us to prevent them to repeat what happened to original Debian leader and what happened to Debian after that.

#89 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-08-19 06:25:12

Head_on_a_Stick wrote:
bimon wrote:

process it with ME_cleaner to remove IntelME, better to libreboot of course if you can get a right hardware

That doesn't completely remove the ME and even if it did there would still be blobs in the motherboard controller firmware.

The FSF only lists a few motherboards that are blob-free: https://ryf.fsf.org/categories/mainboards

Of those boards only the POWER9 versions from Talos offer a decent level of performance. Not cheap though smile

bimon wrote:

ARM hardware (two separated boards) free from X86 backdoors and trojans

ARM is a very opaque architecture, both the motherboard controllers and the Mali graphics require blobs. Again, POWER9 is better (or perhaps RISC-V).

We talk about different price ranges, ganstalkers often attack people on a low budget just to make them even more financially vulnerable trying to get them on their slavery galleys in their corporations.

And I think it is still not easy to verify there are no backdoors in POWER9. And it is a CPU with speculative execution yet most likely vulnerable to SPECTRE and like it? When we talk about getting some better performance than ARM it may be enough to get a cheap system with Libreboot or at least Coreboot, run KVM or software emulation on it and manage it from a secure ARM device.

IMHO Talos is a good toy for wealthy men who can purchase a few of them just for experiments and trash them if they do not like something without any financial regret. I just purchased many ARMv5 and ARMv7 SoCs just for experiments, it is affordable for me and I still do not know if they solve the problems which I experienced in the past, but it is not a significant loss for my budget if something goes wrong for some of those boards.

As for ARM I would not trust anything more recent than old ARMv7 boards like Orange PI with a wireless chip removed from the board.
Modern ARMs may have large BLOBs in their SoC boot ROM and they can have trojans working in an ARM TrustZone.

To make me more confident in a current ARM hardware a vendor would have to provide an open source code for his BROM which is inside a SoC.
It shall be built reproducible and result to the same verifiable binaries which could be read from BROM. But it still most likely does not prevent them to have some   hidden code running in a TrustZone anyway or even making such verifiable BROM a fake ROM while running another proprietary BLOB hidden from us.

On the other hand there are a plenty of Cortex A7 oranges free from speculative issues which are good for a mini server running under OpenBSD.
Please understand performance does not matter at all when we talk about security, slow ARMv7 for $30-$50 may be much better and stronger in these terms than a modern shiny computer for a few thousands of USD.
Beagle bone black boards are already free from radio chips and their BROM is relatively small which is less in size than RAM of a good old ZXSpectrum, unfortunately it is not Cortex A7, therefore it is good only for a secure client SSH terminal, for a micro server it is better to use Cortex A7.

You can install only light and the most critical services like SSH, Firewall, some proxies, DNS, monitoring, intrusion detection, Jabber, e-mail, etc.  on those mini boards while running more resource demanding applications as KVM guests on other Coreboot hosts behind this secure gateway based on ARMv7 CortexA7 + Nitrokey + OpenBSD. Just allow connections to KVM hosts only from secure OpenBSD ARM host.

#90 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-08-19 06:17:07

jobbautista9 wrote:
bimon wrote:

...KDE4 or KDE5, they are full of backdoors and can erase your important ideas in knotes and kalarm at least.

Do you have proof for these claims? And you should probably report those problems with knotes and kalarm to the upstream's or Debian's bug tracker.

I just experienced information lost from KAlarm and KNotes in KDE4 many times after their store was ported from a file system to a database integrated into KDE.
It generally happened when I wrote down some  discrediting evidence against the attackers and when wrote to forum topics like this.
I guess the whole idea about open source backdoors is to make them available as legitimate network services say via TCP sockets, while users think they are protected by a firewall it is not actually the truth because agencies run their invisible trojans in protected rings of modern CPUs (most likely even negative rings) and such trojans can even saliently virtualize your whole computer in addition that X86 itself is not a pure hardware by itself, it is like a VM running on their mutable/updatable microcode. It is not possible to detect those trojans in your operation system, though in a case of virtualization it sometimes may be possible by measuring some calculation speeds of the CPU.

Most likely it is not easy without unified API available via a socket like systemD to manage applications from trojans because it is not easy to conform to ABIs needed to be called and out of process communication without network stack, but via network services it is much easier just like a RPC call.

#91 Re: Hardware & System Configuration » Making Devuan more secure. » 2020-08-18 17:29:37

freenet_bro wrote:

The question might be a bit odd, but I'm currently writing this message from a machine, which is under total surveillance, because of reasons. (I'm a good goy though. Don't worry.)

I was in about the same situation as you a couple of years ago.

I can indicate you some steps to at least remove their active presence on your machine, after that they still can see anything you do and even read your mind.

1) Get an older hardware like Core2 Duo with good old BIOS (instead of UEFI) and process it with ME_cleaner to remove IntelME, better to libreboot of course if you can get a right hardware.

2) Get somewhere a very old SD card of size like 256Mb and an ancient SD card reader USB1 or USB2, they are free from modern firmware backdoors. Place your bootloader and kernel onto this SD card.
Always boot your system from USB SD reader, this prevents injecting trojans during boot phase by storage devices.

3) Encrypt all your HDDs to partially isolate from their firmware trojans.
All file systems shall be created above LUKSed block devices.
Use the shortest SATA cables you can get, 10-15cm are the best, it will make it harder to kill data on your disks by active EMI attacks injecting intelligent noise making your HDD working incorrectly for some time.
And try to always use ZFS, it sees all checksums errors when you are under a EMI attack, otherwise you can silently loose your data and files.

4) Use Devuan without systemD, it is an absolute MUST.

5) Do not use modern bloated DE like KDE4 or KDE5, they are full of backdoors and can erase your important ideas in knotes and kalarm at least. I have found TrinityDE is the best DE for a workstation and NoDM+IceWM+matchbox-desktop is the best thing for a server.
With IceWM you can disable almost all services even like dbus, etc.

6) Never run proprietary software like Skype of Chrome on your sensitive computer, have a dedicated different motherboard for them and run them only in a dedicated KVM on it.

7) For SSH access to other hosts keep your secret keys in hardware devices like Nitrokey PRO2 or HSM2.

8) I am going to make an installation of a combi of Devuan+ZFS volume and OpenBSD running from that volume over a dedicated Ethernet link. They will both run on ARM hardware (two separated boards) free from X86 backdoors and trojans. Add Nitrokey PRO2 or HSM2 here and get a relatively good protection at least from general hackers, agencies still can replace your hardware or reflash something (though I guess it is harder to do on a SoC) and they can enter your room not via a front door or a window (don't ask me how).

May be I will share it in the corresponding forum area for ARM builds.

#92 Re: Hardware & System Configuration » [SOLVED] U2F and FIDO2 tokens in Devuan » 2020-07-16 04:14:59

Well, on ASCII it seems were some problem with Brave browser, Chromium works with FIDO2 very stable on ASCII without X11 redirection.

But I get FIDO2 working neither in Beowulf, nor in Ceres virtual machines and can test only by Firefox and Brave 2019, because more recent Chromium does not display on a remote X11, it tells:

[4404:4453:0716/041633.073598:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[4404:4453:0716/041633.073744:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[4447:4447:0716/041634.091650:ERROR:sandbox_linux.cc(374)] InitializeSandbox() called with multiple threads in process gpu-process.
[4404:4453:0716/041639.708660:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")
[4404:4453:0716/041639.708782:ERROR:bus.cc(393)] Failed to connect to the bus: Could not parse server address: Unknown address type (examples of valid types are "tcp" and on UNIX "unix")

And then it displays a black X11 window without any controls, may be this can be fixed somehow?

Neither Firefox, nor Brave 2019 work with FIDO2 token in Beowulf or Ceres for me sad

#93 Re: Hardware & System Configuration » [SOLVED] U2F and FIDO2 tokens in Devuan » 2020-07-16 02:41:01

I have found an explanation to some of my questions:
https://wiki.gentoo.org/wiki/Pam_u2f

But still cannot fix issues I  have described above, any ideas please?

#94 Re: Hardware & System Configuration » [SOLVED] U2F and FIDO2 tokens in Devuan » 2020-07-16 01:02:53

Another problem on ASCII, though most time FIDO2  works fine on it.

Can you please explain how U2F and FIDO2 works on Linux in terms of how to restart its driver?

Does it use any kernel modules except hid?

If the browser works fine with FIDO2 token for a while and then starts to display an error in a protocol, then how can I reinitialize the token? Ejecting and reinserting it again does not help.

At the same time if running a virtual machine with a Debian Live CD 10.4 the token works again inside the VM guest, so I conclude it is not a problem related to the token, and even more it happens with each of two pieces of the tokens I have.

I guess a reboot will help, but I would like to avoid rebooting my workstation of course.

May be some kernel modules can be reloaded or some service restarted to fix the problem without reboot?

I used following page to test:
https://demo.yubico.com/webauthn-technical/

In Debian LiveCD 10.4 my FIDO2 token passes all tests fine and most time it works fine on ASCII too.

The problem is not related to the token itself for sure, at least it works fine on other computer and in another virtual machine, therefore I conclude the FIDO2 token piece is not an issue here.

#95 Re: Hardware & System Configuration » [SOLVED] U2F and FIDO2 tokens in Devuan » 2020-07-16 01:01:27

root@ceres:/# fido2-token -L
/dev/hidraw0: vendor=0x096e, product=0x0858 (FT FIDO)

root@ceres:/# dpkg -al | grep u2f
ii  libauthen-u2f-perl                                      0.003-1                            all          pure Perl FIDO U2F server library
ii  libauthen-u2f-tester-perl                               0.03-1                             all          FIDO/U2F Authentication Test Client
ii  libcrypt-u2f-server-perl:amd64                          0.45-1+b1                          amd64        Perl module to register and authenticate U2F compatible devices
ii  libpam-u2f                                              1.0.8-1                            amd64        universal 2nd factor (U2F) PAM module
ii  libu2f-host-dev                                         1.1.10-1+b1                        amd64        Development files for the U2F host C library libu2f-host
ii  libu2f-host-doc                                         1.1.10-1                           all          Documentation for the U2F host C library libu2f-host
ii  libu2f-host0:amd64                                      1.1.10-1+b1                        amd64        Universal 2nd Factor (U2F) host communication C Library
ii  libu2f-server-dev                                       1.1.0-3                            amd64        Development files for the U2F server C library libu2f-server
ii  libu2f-server0                                          1.1.0-3                            amd64        Universal 2nd Factor (U2F) server communication C Library
ii  libu2f-udev                                             1.1.10-1                           all          Universal 2nd Factor (U2F) common files
ii  pamu2fcfg                                               1.0.8-1                            amd64        universal 2nd factor (U2F) PAM module command-line helper tool
ii  python3-u2flib-server                                   5.0.0-1.1                          all          Universal 2nd Factor (U2F) server communication Python3 module
ii  u2f-host                                                1.1.10-1+b1                        amd64        Command line tool to do Universal 2nd Factor (U2F) operations
ii  u2f-server                                              1.1.0-3                            amd64        Command line tool to do Universal 2nd Factor (U2F) operations
root@ceres:/# dpkg -al | grep fido2
ii  fido2-tools                                             1.4.0-2                            amd64        command-line tools to configure and use a FIDO 2 token
ii  libfido2-1:amd64                                        1.4.0-2                            amd64        library for generating and verifying FIDO 2.0 objects
ii  libfido2-dev:amd64                                      1.4.0-2                            amd64        library for generating and verifying FIDO 2.0 objects -- headers
ii  libfido2-doc                                            1.4.0-2                            all          library for generating and verifying FIDO 2.0 objects -- documentation
ii  python3-fido2                                           0.8.1-1                            all          Python library for implementing FIDO 2.0

#96 Hardware & System Configuration » [SOLVED] U2F and FIDO2 tokens in Devuan » 2020-07-16 00:56:41

bimon
Replies: 6

Hello,

I have a few installations of Devuan including ASCII and Ceres, both are the latest dist-upgraded.

I have tried the same brave browser on both mentioned installations.

On ASCII it works fine most time, but in Ceres it does not work at all.

Please let me know, how can this be fixed?

Which services are responsible to allow a browser to use FIDO2 token?

What am I missing on Ceres?

lsusb indicates the token on both computers.
/etc/udev/rules.d configured
/dev/hidraw0 appears on both hosts.

#97 Re: Devuan Derivatives » An easy method to get Whonix based on Devuan instead of Debian? » 2020-07-07 17:47:28

https://phabricator.whonix.org/T998

There's no manual.

Too much work. For an idea how much see:

https://forums.whonix.org/t/porting-who … linux/9369

Also discussion on systemd:
https://forums.whonix.org/t/fixing-the- … model/9172

Related, discussion on which operating system Whonix is based on:
https://www.whonix.org/wiki/Dev/Operating_System

May be he does not know that Devuan is almost the same Debian without systemD.

#98 Devuan Derivatives » An easy method to get Whonix based on Devuan instead of Debian? » 2020-07-04 21:41:46

bimon
Replies: 2

Hello,

Please let me know, may be a manual exists about how to switch Whonix to Devuan base and still keep all or most security enhancements of the Whonix project and eliminate systemD from it at the same time?

It has so many security features I am missing:
https://www.whonix.org/#features
including hardened kernel, but unfortunately it uses systemD which is a very serious unacceptable flaw.

May be just installing a few packages mentioned on:
https://web.archive.org/web/20200705173 … bian_Hosts
can do the thing? Though I am not sure about the hardened kernel from Whonix, is there an easy method to borrow its kernel with all its hacks and tunes to Devuan?

#100 Devuan » Archiving Devuan repositories » 2020-06-04 22:49:00

bimon
Replies: 12

I keep /var/cache/apt/archives on a mounted dedicated ZFS dataset like system/apt while having Devuan root on the system/rootfs, also doing regular snapshots and replicated ZFS backups of them to another backup server.

Anyway I would prefer to be able to get all available debs at a specific point of time rather than only debs I ever installed earlier.
So that if I need sometimes in the future a package I did not use earlier I would not need to try to find it somewhere on the Internet.

Did you ever try recently (in 2020) to find an unused earlier deb file say for a Wheezy Debian v7 especially without DVD sets and without Debian http://snapshot.debian.org/
Yes, Wheezy is sometimes still used in Virtual machines and works very well,
btw. its KVM host is powered by modern Devuan.

What if say 5 years later I will need some server package for a ASCII release, how to get it?

Does a single 4GB desktop Devuan DVD contain at least all Devuan specific (non Debian) debs ever released and available by apt-get at the time of ISO generation?

I refer to, e.g. for ASCII:
https://mirror.leaseweb.com/devuan/devu … _dvd-1.iso

Do any Devuan specific debs freed from systemD (not present in original Debian) exist beyond of that 4GB ISO only online by apt-get and not on that ISO?

Can your merging magic for Debian+Devuan repos  be deployed or installed locally?
Can I have my local http or ftp server which would merge together all available ISOs dynamically on demand like your own mirrors do?
Say 1x4GB Devuan ISO and 3x4GB Debian ISOs would produce a single point of complete Devuan packages set if mounted in some specific way may be with your http redirection installed locally and with a customized sources.list ?

My primary usage of Devuan is for servers though I use it on my Trinity desktop computer too.
For servers it is not a good idea to miss any server package from ISO, if something goes wrong with Devuan website or Internet connection or anything else we require to have all deb files (even those were not ever installed yet) from the distribution locally, it was an absolute MUST before systemD have not left us a choice. It is especially important for older releases. What happens to your online Jessie or ASCII repository when original Debian v8 and v9 are outdated and removed from online Debian repositories?
How to manage old servers which we do not want to upgrade for some reasons, we do not like an idea to always install the latest release, unavoidable upgrades are something like Windows 10 and systemD  itself being forcefully imposed on Debian users, it is a lack of freedom to be forced to always upgrade if it is not needed. Though I like current Beowulf release very much I may still need to maintain some older releases in virtual machines, but may be I will not like future Devuan release say in 3-5 releases later since today, hope it will not happen, but who knows?

Also we cannot wait to allow online Devuan mirrors to go back or our Internet connection to be recovered if something happened there, we may need an access to some earlier not installed yet deb file ASAP.

Another point, would not it be a good idea to provide Devuan server releases without any desktop components earlier than desktop capable? I do not need any modern KDE, Gnome or anything like it, I am happy with Trinity on ASCII, most likely I can survive with my current Trinity and ASCII for future 3-5 years or even more without upgrading my desktop, but on some servers I would prefer to have Devuan not much behind of current Debian stable. Would not it be easier (less development resources needed) to maintain special server edition of Devuan without graphics packages at all which could be released soon after corresponding Debian release?

Board footer

Forum Software