Activity for Cálestyo
-
Cálestyo created ticket #9
add option to return a non-zero exit staus if -n was used and a file couldn't be extracted
-
I don't think sshpass could ever guarantee that a passphrase given as argument cannot be viewed by others, even if it would overwrite it. The OS might still export the original command line somehow and even if it wouldn't there's always the small time frame between starting the process (where the passphrase would be visible) and overwriting it, where an attacker could see it. Your only chance is if the OS prohibits users to see the command arguments of processes from other users.
-
crashes when directory is `.`, `..` or starts with a `.`
-
One more thought about it: e) Maybe, what sshpass would need was even another way to specify the passphrase... something like -c "command", in which command is a shell command executed via system(3). sshpass could simply check it's exit status and if 0 take whatever was printed to stdout and use that ass password (including any newlines and so). Exit status 1 would indicate errors, others could be reserved for future use. Of course one would also need to educate users that they mustn't include any...
-
I've never migrated a project from SF to git(lab/hub)... not sure whether the latter provide any migration tools, so that one could keep all the issues etc.. But at least the repo should be possible.
-
consider switching to git[lab/hub/etc.]
-
I put some more thinking into this,... so for the records: a) with scp, one might have actually any number of remote sides (it allows 1-n sources and 1 destination), all of them may have 0-i hops and each of those may have 0-m password/OTP prompts... b) the prompts may be identifiable (like in "(user@example.org) Your 2nd factor (user):" or non-identifiable (like in"OTP:") c) it may probably make sense to match using regular expressions (ideally probably PCRE), so if one has one OTP secret or password...
-
Nice. Thanks.
-
This wouldn't just be important for multiple prompts with e.g. OTP + password or multi-hop, but also for scp when using remote hosts as both source and destination. So one likely would need a way to specify an order in which certain strings are expected and passwords used for it. Maybe something like pairs of [-f|-d|-p] and -P belonging together. For -e this would require means to specify different env vars, for -f and -d each next pair could simply read the next line if the same file/descriptor...
-
I should perhaps add that there are two aspects to this issue. 1) Non-security-related ... in the sense that sshpass shouldn't "spoil" the remote environment with env vars that are not really intentionally sent to the remote end. The user might have his own SSHPASS env var, which he sometimes sends... and which is not the one from sshpass. (This is also why I've asked for the ability to change the var for -e). 2) Security-related... i.e. the length of the passphrase is disclosed. Not so critical...
-
don't export SSHPASS to the invoked process (ssh)
-
allow to specify a different env var than SSHPASS
-
Thx :-)
-
Aweseome! Thanks :-) Hope it will find it's way back into Debian.
-
port to GTK3
-
I'd like to see that, too. Even better would be to simply fall back to e.g. ffmpeg for decoding, if a format is natively unknown.
-
Three things to add here that came to my mind: 1) In such "file-has-been-moved" markers... one should think whether it makes any sense, not just to include the most recent previous pathname (i.e. the old pathname of the file from the most recent archive of reference) but also all previous pathnames. Right now I cannot think of any case where this would be beneficial, but there may be one. 2) For very small files, dar should possibly check whether storing just storing both: - the full file (including...
-
@Denis ... this and several other feature request that are already marked as implemented,... are still marked as open as well... perhaps it would be helpful to mark them all as closed :-)
-
Some random addition to this (beware, I'm not a crypto expert): In disk encryption (i.e. dm-crypt/LUKS/etc.) there was until recently (when dm-integrity was added to the linux kernel) no real cryptographic integrity protection. At first this means of course: any attacker can modify a ciphered block, and it will be decrypted (in our case by the signed key) to some (of course wrong) clear text block. The clear text block could be just garbage (with some chance to notice this) or maybe there are even...
-
as you described there is no simple solution to detect file move without increasing either memory requirement (hash/UUID comparison table) or I/O count Well I think the two methods proposed above ((a)=based on fs UUID + inode-#,.. (b)=based on custom user XATTR UUID) should be pretty fast, shouldn't they? AFAIU dar loads the catalogue anyway already fully into RAM when doing an differential backup doesn't it? If it does, it could just put the IDs (either (fs+UUID+inode) or (custom user XATTR UUID))...
-
Hey Denis. I see. Actually I think this should be documented sowhere in the manpage, as it's some valuable information about the resilience of the dar format. I think the way you do this (hash per amount of storage vs. hash per file) is really nice, actually I was already about to advise this in addition to using something "stronger" than CRC32. As you say, having the on-the-fly calculated hash from --hash is really nice as well (especially because of things like disk corruption and so on, if one...
-
And what about my last comment, where I argued that extenting the hash algos would make sense? Shall I open a new feature request for this?
-
(based upon https://sourceforge.net/p/dar/bugs/204/)
-
support higher time resolutions
-
I'd still like to see the feature to have one or even several other digest types per file, and I think there is quite some value to this. First, any hash alone does of course not prevent against intentional modifications (because the hash can be forged too)... but against accidental. And there, other algorithms have far better resistance than CRC(32?)... CRC32 is 32 bit, SHA3-512 is 512 bits... thats obviously many magnitudes more, giving much better collision resistance especially for large files...
-
removed, was bogus
-
I was thinking about this issue (how an incremental/differential backup could track movements of files) for quite a while now... First, I think the typical use case for this is not system backups, at least not the "system parts" like /usr, /lib, /var, and so on... as these locations are typically rather static and files don't move that much. It's more about "precious" data in some archives, things like photography collections and so on. I have myself a big archive of data, that piled up over my life......
-
"isolated catalog do contain data CRC" Is this still true? Cause the manpage seems to claim different: "Thus you can do all operations on an isolated catalogue, in particular take it in place of the original backup as reference for a differential archive, archive testing, archive comparison. Note however that for comparison (-d option) as data is not present in the isolated cata‐ logue, dar relies on embedded CRC rather than comparing data byte by byte...."
-
ISRC/CATALOG detection issues
-
CUERipper detects an INDEX 01 954437:10:45 and fails to rip
-
strange double status entries in the CUERipper log files
-
CUERipper/EAC-Plugin: try to avoid counting one's own confidence submissions
-
make it possible to retain one's DB ID after hardware changes
-
SecureMode setting is not restored to on starting CUERipper
-
6) Oh and it seems current regexps assume one could write directive=value, but I...
-
SSH PermitRootLogin is fragile and incomplete
-
Sure, as I wrote... I just said it would be a better default to use a subdir, since...
-
Well I simply thought changing it wouldn't hurt, and as the current way it's done...
-
As far as I can see you've also added USER_FILEPROP_FILES_DIRS=/etc/rkhunter.d/*...
-
well I'm fine with the default, but please correct the comment then =)
-
I'll read/check/answer this later... I'm currently on vacation :-)
-
Oh and as noted in bug #453, contrary to what --longhelp claims, --nogaptags seems...
-
gapless decoding issues
-
manpage and program usage outdated
-
Hey Henrik. Rok just pointed me here. I'm a bit surprised to see this bug closed...
-
Hi John. This was against 1.4.2 from Debian. Cheers, Chris.
-
Hey. Well if you discuss this anyway already,...it's fine for me. But strictly speaking...
-
Sorry for the ugly formatting... SF sucks... ^^ the numbers are line numbers, though,...
-
wildcards in ALLOWPROCDELFILE do not work
-
WHITELISTED_IS_WHITE seems to no longer change anything
-
default values of list options get "lost" when setting the options manually
-
DISABLE_TESTS=NONE leads to an error
-
document which standard checks use which elementary tests
-
undocumeted check named "checksysinfo3"
-
some files/paths to add to the example option values
-
default rkhunter.conf diverges from defaults
-
some pathname options still use space separated lists
-
Oh and everything I've said for /var/lib/rkhunter/tmp/ applies of course as well...
-
does STARTUP_PATHS and related checks need to be adapted to systemd?
-
Seconded. Either sha512 should be default or even better (once it arrives) SHA3 /...
-
Even more actually: 3) The copying of files a long is in principle already a problem,...
-
security of files copied by rkhunter
-
place rkhunter logfiles in their own subdirectory
-
disable SSLv3 per default
1
