Day changed to 2024-05-04
[03:30] jfw: http://jfxpt.com/2024/regrinding-busybox-archive-extraction-fixing-directory-timestamps-symlink-attacks-a-buffer-overflow-and-more/
Day changed to 2024-05-05
[21:07] dorion: http://dorion-mode.com/2024/05/coming-out-of-the-shadows-finally/
Day changed to 2024-05-06
[00:41] dorion: http://dorion-mode.com/2024/05/philosophy-is-laughter/
Day changed to 2024-05-08
[18:07] jfw: cruciform asked about SSD recommendations; for the Thinkpads we've pretty much been sticking with Samsung EVO, following the TMSR gossip - which AFAIK was indeed just gossip, no data.
[18:08] jfw: these however are consumer rather than 'enterprise' SSDs, for instance you're supposed to 'fstrim' them as they don't reserve capacity internally for wear leveling / garbage collection or however it works.
[18:10] jfw: there's this documented instance of a bit flip on disk on such a system but we don't know where it came from, possibly bad DRAM
[18:13] jfw: then this one is a clear failure by the SSD on a different machine
[18:14] jfw: I myself had this trouble but it seemed to implicate the apu1 rather than the drive
[18:17] jfw: here a PNY microSDHC card failing me in an unforgivable manner
[18:17] sourcerer: 2022-09-14 05:44:23 (#jwrd) jfw: apropos of those storage formatting observations, I've discovered a 16 GB PNY microSDHC card has failed dramatically, after a mere ~17 months of use in a car music player i.e. supposedly a read-mostly load.
Day changed to 2024-05-09
[00:39] jfw: but to sum up, there's enough anecdotes of failures that I don't view the samsung ssds as particularly holy; on the other hand they've often worked fine and we don't have enough data to make a statistical case either way, nor on the alternatives; personally I'm still fine with buying them
Day changed to 2024-05-14
[15:01] whaack: howdy
[15:02] whaack: dorion/jfw do you want to catch up through some vc medium in the near future?
[18:37] whaack: looks like somehow i managed to erase one of my wallets, it's as if i ran rm * in the wallet and then did gbw-save
[18:37] whaack: when i gbw-open he wallet ijust get an empty folder
[18:40] whaack: this is a big wtf moment for me. any way i may have accidently done this? i just dont know how the wallet is in this state
[20:42] dorion: whaack, sorry to hear about the troubles, I can vc sometime later this week. do you have a backup ?
[20:45] jfw: whaack, a catchup sounds good. re wallet, how about going through the steps manually - gpg decrypt it to get the tar file, then check what's in that (tar -tvf)
[21:01] whaack: jfw: gpg decrypt gives an empty file
[21:01] whaack: dorion: yes its backed up
[21:01] whaack: it's*
[21:18] jfw: whaack: empty as in zero bytes?
[21:19] jfw: (iirc a tar file with nothing in it will still have some zero-records)
[21:25] jfw: checking the gbw-save code it's actually done quite carefully so as to commit to disk before replacing the old file so there's nothing lost even in a system crash, nor will it proceed if the wallet tree to be saved doesn't exist, and the automatic tracking of paths through shell variables makes it pretty hard to mess up filenames or whatever (none of the commands but gbw-open and gbw-init even
[21:25] jfw: take any arguments)
[21:28] jfw: actually hmm, it's possible it would continue if the 'tar' fails, as its exit status is lost in the pipeline
[21:30] jfw: is it possible you manually deleted the whole dir in /tmp (not via gbw-discard or gbw-close) then did a save?
[21:30] whaack: jfw: im guessing that's what happened
[21:31] whaack: and yes 0 bytes
[21:45] jfw: ok, gnu tar produces a 10240 byte file but busybox tar produces a 0 byte file in this case. neither one does it silently though
[21:47] jfw: eg if I remove the /tmp/tmp.XXXXXX entirely, "tar: can't change directory to '/tmp/tmp.XXXXXX': No such file or directory", or if I remove only the wallet subdir, "tar: wallet: No such file or directory" "tar: error exit delayed from previous errors"
[21:49] jfw: so, this could be improved to prevent overwriting the encrypted file if the tree fails to exist entirely. but I also have to wonder why?!! would you do this? doesn't seem that much different from deleting the contents in which case it's indeed doing what you told it to
Day changed to 2024-05-15
[18:06] dorion waves from miami, about to high five jwm.
[18:18] jfw: what up jwm!
Day changed to 2024-05-17
[17:13] jfw: http://jfxpt.com/2024/poking-at-a-swarm-of-gnats/
[03:30] jfw: http://jfxpt.com/2024/regrinding-busybox-archive-extraction-fixing-directory-timestamps-symlink-attacks-a-buffer-overflow-and-more/
Day changed to 2024-05-05
[21:07] dorion: http://dorion-mode.com/2024/05/coming-out-of-the-shadows-finally/
Day changed to 2024-05-06
[00:41] dorion: http://dorion-mode.com/2024/05/philosophy-is-laughter/
Day changed to 2024-05-08
[18:07] jfw: cruciform asked about SSD recommendations; for the Thinkpads we've pretty much been sticking with Samsung EVO, following the TMSR gossip - which AFAIK was indeed just gossip, no data.
[18:08] jfw: these however are consumer rather than 'enterprise' SSDs, for instance you're supposed to 'fstrim' them as they don't reserve capacity internally for wear leveling / garbage collection or however it works.
[18:10] jfw: there's this documented instance of a bit flip on disk on such a system but we don't know where it came from, possibly bad DRAM
[18:13] jfw: then this one is a clear failure by the SSD on a different machine
[18:14] jfw: I myself had this trouble but it seemed to implicate the apu1 rather than the drive
[18:17] jfw: here a PNY microSDHC card failing me in an unforgivable manner
[18:17] sourcerer: 2022-09-14 05:44:23 (#jwrd) jfw: apropos of those storage formatting observations, I've discovered a 16 GB PNY microSDHC card has failed dramatically, after a mere ~17 months of use in a car music player i.e. supposedly a read-mostly load.
Day changed to 2024-05-09
[00:39] jfw: but to sum up, there's enough anecdotes of failures that I don't view the samsung ssds as particularly holy; on the other hand they've often worked fine and we don't have enough data to make a statistical case either way, nor on the alternatives; personally I'm still fine with buying them
Day changed to 2024-05-14
[15:01] whaack: howdy
[15:02] whaack: dorion/jfw do you want to catch up through some vc medium in the near future?
[18:37] whaack: looks like somehow i managed to erase one of my wallets, it's as if i ran rm * in the wallet and then did gbw-save
[18:37] whaack: when i gbw-open he wallet ijust get an empty folder
[18:40] whaack: this is a big wtf moment for me. any way i may have accidently done this? i just dont know how the wallet is in this state
[20:42] dorion: whaack, sorry to hear about the troubles, I can vc sometime later this week. do you have a backup ?
[20:45] jfw: whaack, a catchup sounds good. re wallet, how about going through the steps manually - gpg decrypt it to get the tar file, then check what's in that (tar -tvf)
[21:01] whaack: jfw: gpg decrypt gives an empty file
[21:01] whaack: dorion: yes its backed up
[21:01] whaack: it's*
[21:18] jfw: whaack: empty as in zero bytes?
[21:19] jfw: (iirc a tar file with nothing in it will still have some zero-records)
[21:25] jfw: checking the gbw-save code it's actually done quite carefully so as to commit to disk before replacing the old file so there's nothing lost even in a system crash, nor will it proceed if the wallet tree to be saved doesn't exist, and the automatic tracking of paths through shell variables makes it pretty hard to mess up filenames or whatever (none of the commands but gbw-open and gbw-init even
[21:25] jfw: take any arguments)
[21:28] jfw: actually hmm, it's possible it would continue if the 'tar' fails, as its exit status is lost in the pipeline
[21:30] jfw: is it possible you manually deleted the whole dir in /tmp (not via gbw-discard or gbw-close) then did a save?
[21:30] whaack: jfw: im guessing that's what happened
[21:31] whaack: and yes 0 bytes
[21:45] jfw: ok, gnu tar produces a 10240 byte file but busybox tar produces a 0 byte file in this case. neither one does it silently though
[21:47] jfw: eg if I remove the /tmp/tmp.XXXXXX entirely, "tar: can't change directory to '/tmp/tmp.XXXXXX': No such file or directory", or if I remove only the wallet subdir, "tar: wallet: No such file or directory" "tar: error exit delayed from previous errors"
[21:49] jfw: so, this could be improved to prevent overwriting the encrypted file if the tree fails to exist entirely. but I also have to wonder why?!! would you do this? doesn't seem that much different from deleting the contents in which case it's indeed doing what you told it to
Day changed to 2024-05-15
[18:06] dorion waves from miami, about to high five jwm.
[18:18] jfw: what up jwm!
Day changed to 2024-05-17
[17:13] jfw: http://jfxpt.com/2024/poking-at-a-swarm-of-gnats/