Re: [mc] history not always history
On Sun, 2023-08-06 at 23:48 +0200, mi via mc wrote: > supercomputing is very expensive and even in rich countries there are only a few of these machines. Even if quantum computers should meet all requirements in the near future, computing time will be many times more expensive than today's supercomputing, and these machines will be even rarer and more desirable than today's supercomputers. To think that anyone would waste this precious resource and spend a lot of money to crack an encryption on a private computer is nonsense. Reason for valid doubts are other vulnerabilities, such as the firmware of disk drives and wide- open barn doors of microchips. -- mc mailing list mc@lists.midnight-commander.org https://lists.midnight-commander.org/mailman/listinfo/mc
Re: [mc] history not always history
Rob, I knew it, you're a timetraveller (-AI) ! As the Sony PS66 would be released around y 2360 (on a linear schedule) and i wonder what at that time, 'long out of date' exactly would be ... > Haha. The machine I did this on was a PS66, long out of date even then. > But the scheme really caused no perceptible performance hit. A slight > boot delay while encrypting the loop device, but I wasn't doing that > very often, so no harm there. just joking Back to the topic ... i think that standard encryptions with 512 or even 1024 bits are no more safe with the progress of supercomputing, and even John Doe can do it with DAS. But an awful lot of applications leave history (more or less all of them) and if you want to avoid that on a laptop, there's probably no way around a VM kiosk system. And i think i'm going to go there. -- mc mailing list mc@lists.midnight-commander.org https://lists.midnight-commander.org/mailman/listinfo/mc
Re: [mc] history not always history
On 2023-08-06 11:31, mi via mc wrote: Encrypting swap reminds me of that experiment, decades ago, when a > friend moved swap to a floppy disk. Hahaha. Immediately frozen. What a deal! Haha. The machine I did this on was a P166, long out of date even then. But the scheme really caused no perceptible performance hit. A slight boot delay while encrypting the loop device, but I wasn't doing that very often, so no harm there. Of course to be realistic about the threat model, local LEAs are not going to have the ability to deal with a Linux system, much less get data out of swap, and even less to be able to break swap encryption. Even at the time I knew this, but I did it anyway because it was fun. :) -- http://rob0.nodns4.us/ -- mc mailing list mc@lists.midnight-commander.org https://lists.midnight-commander.org/mailman/listinfo/mc
Re: [mc] Strange behavior of ftp vfs
I just want to add to this old thread, that there were some issues with Android 13 and probably some earlier (can't remember) when access for folders (not the general FS access) has to be explicitly granted for apps other then system apps. These apps need to go by the system Storage Access Framework now to get that permission explicitly first. Meaning you have to give clearance. I don't know about commandline ftp but my android ftp server then needed a one-time permission for 'home' folder and i cannot change into another one (except subfolders) with client app. A cd will not barf but has no effect. Also, the path to storage chip "/" had changed at some point, i had to update to /storage/emulated/0. > today i noticed a strange behavior of the ftp vfs of mc (4.8.22 here), > maybe someone can explain. > I connected to the wifi ftp server of my phone, as i did often before: > > ftp account: android@192.168.0.242:2221 > > I was able to see the directories and change to the one i wanted to, > tried to put some files to my local directory. Mc said: can't read the > file, no rights to do so. I reconnected three times, all the same. Third > time i tipped Enter key on one of the (picture) files. Ftpvfs began to > load the file (counts up the bytes) and when finished, started gwenview > and showed the picture, could save it from there to my local disk. Strange. > Started plain ftp on cmdline for the account, went to the directory, ls > the files, all of r--r--r-- rights. No problem to download them to my > local disk. Tried to do so by mc oncemore: no rights. > > The ony reason i can think of is that the bandwith of the wifi here is a > bit poor because of some iron between me and the AP. But why did load > the ftp vfs the picture then, when clicked? > > -- > cu > > jth > -- > mc mailing list > mc@lists.midnight-commander.org > https://lists.midnight-commander.org/mailman/listinfo/mc -- mc mailing list mc@lists.midnight-commander.org https://lists.midnight-commander.org/mailman/listinfo/mc
Re: [mc] history not always history
Thanks, Rob and Andrew ! I can merge the two suggestions ... in a login script like ~/.profile or some script around starting X session, mkdir -m 0600 /tmp/mc && export MC_PROFILE_ROOT=/tmp/mc I've moved /tmp to tmpfs on all my machines, many years ago. I think it's even default now on most distros, and since quite some time ? I'm also copying ini now. To clarify i inserted a custom section on top, like [hello_santa] ho_ho_ho=1 and it seems to work. One more question, mc seems to create a folder /tmp/mc-user (by username) and it's always empty for me. Does anybody know what this is used for ? Encrypting swap reminds me of that experiment, decades ago, when a friend moved swap to a floppy disk. Hahaha. Immediately frozen. What a deal! -- mc mailing list mc@lists.midnight-commander.org https://lists.midnight-commander.org/mailman/listinfo/mc
[mc-devel] Help testing release candidate / mc-4.8.30-rc1
Hi there, TLDR; I would appreciate if you could please test the following tarball on your systems and report any blocker regressions as compared to the previous 4.8.29 release: https://midnight-commander.org/nopaste/tarball/mc-4.8.30-pre1.tar.xz $ sha256sum mc-4.8.30-pre1.tar.xz f6eace8bd48b2ff07c69ae1a91e93348e5e07ce4ea72cad0dcd763a81c337c53 mc-4.8.30-pre1.tar.xz I've built this tarball out of the latest master with translations from Transifex pulled in on a fresh Fedora 38 VM, which I'm also going to use to build the final release in about a week from now (or earlier) if nothing serious comes up. Many thanks! -- Sincerely yours, Yury V. Zaytsev -- mc-devel mailing list mc-devel@lists.midnight-commander.org https://lists.midnight-commander.org/mailman/listinfo/mc-devel
[mc] Help testing release candidate / mc-4.8.30-rc1
Hi there, TLDR; I would appreciate if you could please test the following tarball on your systems and report any blocker regressions as compared to the previous 4.8.29 release: https://midnight-commander.org/nopaste/tarball/mc-4.8.30-pre1.tar.xz $ sha256sum mc-4.8.30-pre1.tar.xz f6eace8bd48b2ff07c69ae1a91e93348e5e07ce4ea72cad0dcd763a81c337c53 mc-4.8.30-pre1.tar.xz I've built this tarball out of the latest master with translations from Transifex pulled in on a fresh Fedora 38 VM, which I'm also going to use to build the final release in about a week from now (or earlier) if nothing serious comes up. Many thanks! -- Sincerely yours, Yury V. Zaytsev -- mc mailing list mc@lists.midnight-commander.org https://lists.midnight-commander.org/mailman/listinfo/mc
Re: [mc] history not always history
On Sun, 6 Aug 2023 08:18:30 -0500 Rob McGee via mc wrote: > On 2023-08-05 21:00, mi via mc wrote: > > > > It rather looks like erase history with Shift+H then Shift+Delete does > > not delete > > anything in ~/.local/share/mc/history ... and ~/.config/ini other_dir has > > one very > > old entry, it seems like an artefact. > > My thought (and this would have fit better in the other thread) would be to > put > your $HOME on tmpfs. Your history saves normally, and it's usable from > session to session, > until a reboot. There is another way, not so extreme. You can define environment variable $MC_ROOT_PROFILE with the path to the directory where _all_ mc user files will be located (see man mc for details): $ MC_PROFILE_ROOT=/home/andrew/mc-tmp-root mc -F Home directory: /home/andrew Profile root directory: /home/andrew/mc-tmp-root [System data] Config directory: /etc/mc/ Data directory: /usr/share/mc/ File extension handlers: /usr/lib/mc/ext.d/ VFS plugins and scripts: /usr/lib/mc/ extfs.d:/usr/lib/mc/extfs.d/ fish: /usr/lib/mc/fish/ [User data] Config directory: /home/andrew/mc-tmp-root/.config/mc/ Data directory: /home/andrew/mc-tmp-root/.local/share/mc/ skins: /home/andrew/mc-tmp-root/.local/share/mc/skins/ extfs.d:/home/andrew/mc-tmp-root/.local/share/mc/extfs.d/ fish: /home/andrew/mc-tmp-root/.local/share/mc/fish/ mcedit macros: /home/andrew/mc-tmp-root/.local/share/mc/mc.macros mcedit external macros: /home/andrew/mc-tmp-root/.local/share/mc/mcedit/macros.d/macro.* Cache directory: /home/andrew/mc-tmp-root/.cache/mc/ Just remove this directory after exiting mc. -- Andrew -- mc mailing list mc@lists.midnight-commander.org https://lists.midnight-commander.org/mailman/listinfo/mc
Re: [mc] history not always history
On 2023-08-05 21:00, mi via mc wrote: It rather looks like erase history with Shift+H then Shift+Delete does not delete anything in ~/.local/share/mc/history ... and ~/.config/ini other_dir has one very old entry, it seems like an artefact. My thought (and this would have fit better in the other thread) would be to put your $HOME on tmpfs. Your history saves normally, and it's usable from session to session, until a reboot. You could populate your ~/.mc and other settings from safe defaults, with a script at boot time. (In cases where you do need to save settings changes, you can update the safe defaults with a simple cp command.) tmpfs in Linux uses swap to keep files out of active RAM. So this is an issue I solved long ago: at boot time I generated a random passphrase to encrypt the loop device. Even I could not decrypt it, because the passphrase was never saved. Note: this scheme was created for similar concerns. I am thankful that in the ~24 years since then, the feared attack never occurred. I did, however, suffer a theft of my machine in 2008 (not by police.) # mc --version... -- http://rob0.nodns4.us/ -- mc mailing list mc@lists.midnight-commander.org https://lists.midnight-commander.org/mailman/listinfo/mc
