search for: preimag

Hi, I just completed a really big rsync described earlier. Ie about 13,945 directories transfered about 600GB of data. Of 13,945 directories, 13,9441 directories transfer with matching du -b sizes of the preimage to the size of the destination machine image. of the 4 remaining directories i found source vs destination in bytes --------- a) 20480 vs 34922496 b) 28672 vs 24576 c) 61718528 vs 61714432 d) 157790208 vs 157786112 each directory consists of subdirectories of m...

On Tue, 2006-02-21 at 14:58 -0800, rsync2eran@tromer.org wrote: > A year ago we discussed the strength of the MD4 hash used by rsync and > librsync, and one of the points mentioned was that only collision > attacks are known on MD4. Could you please forward this into the bug tracker so it's not lost? -- Martin -------------- next part -------------- A non-text attachment was

...=ramdisk.gz ramdisk_size=65536 root=/dev/ram0 LABEL bzImage20w MENU LABEL ^I: bzImage20w 386 build with 2.6.20 git 01-25-2007 KERNEL bzImage20w APPEND initrd=ramdisk.gz ramdisk_size=65536 root=/dev/ram0 LABEL Images MENU LABEL ^S: Images Help File KERNEL cat.c32 imagesv LABEL PreImage MENU LABEL ^T: Pre-Image Help File KERNEL cat.c32 preimage LABEL Startup MENU LABEL ^U: Start Up Help File KERNEL cat.c32 startup LABEL Startup MENU LABEL ^V: Disclaimer File KERNEL cat.c32 disclaim TIMEOUT 600 ONTIMEOUT bzImageb Don't know if there is a better way...

...29.git MENU LABEL ^K: bz29.git 386 build 03-04-2009 KERNEL bz29.git APPEND initrd=ramdisk.gz ramdisk_size=65536 root=/dev/ram0 LABEL memtest86-3.2 MENU LABEL ^M: memtest86+-1.70 KERNEL memtest86 LABEL Images MENU LABEL ^S: Images Help File KERNEL cat.c32 imagesv LABEL PreImage MENU LABEL ^T: Pre-Image Help File KERNEL cat.c32 preimage LABEL Startup MENU LABEL ^U: Start Up Help File KERNEL cat.c32 startup LABEL Startup MENU LABEL ^V: Disclaimer File KERNEL cat.c32 disclaim TIMEOUT 600 ONTIMEOUT bz28.7 initrd=ramdisk.gz ramdisk_size=65536 root=/de...

On Tue, Sep 24, 2013 at 10:21 PM, Aris Adamantiadis <aris at 0xbadc0de.be> wrote: [snip] > I've worked this week on an alternative key exchange mechanism, in > reaction to the whole NSA leaks and claims over cryptographic backdoors > and/or cracking advances. The key exchange is in my opinion the most > critical defense against passive eavesdropping attacks. > I believe

Hi all, Since the vault for 7.3.1611 has been cleared out last sunday (20170207) - why is that? - I'm using git to download a "SRPM", or more accurately, its contents. However, using git has one major drawback: It is missing checksums for the files. Are there any plans to provide checksums for the files in git so I can be sure that what I download is actually not tampered with?

Hi, I was sure I sent this to openssh at openssh.com, but cannot find that email now in my Sent mailbox, so I am sending it to the developers list. I took a liberty and wrote an I-D with accompanying patch (with contributions from Ondrej Caletka) to support ECDSA in the SSHFP DNS resource record. The I-D is here: https://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa-sha2 (and the source XML

On 02/23/2017 01:03 PM, Lamar Owen wrote: > On 02/23/2017 03:32 PM, James Hogarth wrote: >> On 23 February 2017 at 19:55, Lamar Owen <lowen at pari.edu> wrote: >>> Not to stir up a hornets' nest, but how does Google's announcement at >>> https://shattered.it affect this now? (Executive summary: Google has >>> successfully produced two different

...config bz4x5.0 bz4x5.0.config cat.c32 COPYING cpuid.c32 cpuidtest.c32 disclaim display.c32 dmitest.c32 eltorito.sys failsafe.cfg hdt.c32 ldlinux.c32 libcom32.c32 libgpl.c32 libmenu.c32 libutil.c32 linux.c32 ls.c32 meminfo.c32 memtest menu.c32 menu.lst modules.pcimap pci.ids pcitest.c32 poweroff.c32 preimage reboot.c32 startup syslinux.cfg syslinux.dir test.png vesainfo.c32 vesamenu.c32 vpdtest.c32 Added Directory bootcd/isolinux/EFI: BOOT bootcd/isolinux/EFI/BOOT: cat.c32 cpuid.c32 cpuidtest.c32 display.c32 dmi.c32 efiboot.img hdt.c32 ldlinux.e32 libcom32.c32 libgpl.c32 libmenu.c32 libutil.c32 lin...

I had a busy mailserver fail on me the other day. Below is what was printed in dmesg. We first suspected a hardware failure (raid controller or something else), so we moved the drives to another (identical hardware) machine and ran fsck. Fsck complained ("short read while reading inode") and asked if I wanted to ignore and rewrite (which I did). After booting up again, the problem came

On 15 January 2016 at 08:48, Alex Bligh <alex at alex.org.uk> wrote: > > The socket option is enabled *after* connection establishment, thus > > doesn't protect against SYN floods. This is because server doesn't > > know (in userspace) what the address of the peer is until they > > connect. Again because signed addresses. > So could they exchange a secret

Hi everyone, Not sure if you've read http://www.win.tue.nl/hashclash/SoftIntCodeSign/ . should some kind of advisory be sent to advise people not to rely solely on MD5 checksums? Maybe an update to the man page is due ? : " MD5 has not yet (2001-09-03) been broken, but sufficient attacks have been made that its security is in some doubt. The attacks on MD5 are in the

We still have MD5 as our default password hash, even though known-hash attacks against MD5 are relatively easy these days. We've supported SHA256 and SHA512 for many years now, so how about making SHA512 the default instead of MD5, like on most Linux distributions? Index: etc/login.conf =================================================================== --- etc/login.conf (revision