search for: checksumes

Hi, this small series moves the OCaml Checksums module from virt-builder to mllib, adding more features to use it also for v2v. Thanks, Pino Toscano (4): mllib: move Checksums from builder mllib, builder: add and use Checksums.of_string mllib: add SHA1 support in Checksums v2v: -i ova: use Checksums builder/Makefile.am | 2 -- builder/builder.ml | 6 +++-

Extend Index_parser.entry to hold a list of checksums to validate, and validate all of them. This does change nothing currently, as only sha512 is read, while still allowing us to fetch more checksums if needed. --- builder/builder.ml | 6 +++--- builder/checksums.ml | 3 +++ builder/checksums.mli | 3 +++ builder/index_parser.ml | 22 +++++++++++++++-------

Quoting Karolin Seeger (kseeger at samba.org): > Release Announcements > ===================== > > This is a security release in order to address CVE-2010-2063. > > > o CVE-2010-2063: > In Samba 3.3.x and below, a buffer overrun is possible in chain_reply code. As this issue also affect the 3.2 series of samba (which is no longer officially supported by the Samba

On Tue, Dec 03, 2013 at 01:00:23PM +0000, Balraj Singh wrote: > Hi, > > I''m working on verifying TCP checksums on incoming packets in Mirage, but > I''ve run into a bit of a problem. > > If TCP checksum offload is turned on on a virtual interface (this is the > default), and if the TCP connection is local to the machine, it looks like > Xen does not

Originally an attempt to fix: https://bugzilla.redhat.com/show_bug.cgi?id=1570407 However this isn't a complete fix. The OVA supplied doesn't even conform to VMware's own "specification" (I use the word loosely). The OVF inside the OVA references the disk.vmdk file, but the OVA doesn't contain that disk.vmdk file, only a snapshot called disk.vmdk.000000000. Therefore

Move the Checksums module from virt-builder mostly as it is; the only change is that on checksum mismatch an exception is raised rather than invoking "error" directly: this way users of verify_checksum & verify_checksums can do their own handling of the situation. --- builder/Makefile.am | 2 -- builder/builder.ml | 6 +++++- builder/checksums.ml | 57

On Sunday, January 26, 2020 3:58:31 PM CET Pete Biggs wrote: > > what does Centos 7 do with UPD packets having invalid checksums? > > By default I assume they are just dropped - that's what should happen. Hm that's what thought. > > Are such packets inevitably dropped? > > Applications can specifically disable checksum checking for the kernel > network stack

Hi, what does Centos 7 do with UPD packets having invalid checksums? Are such packets inevitably dropped? Does a network card drop them when it does checksum verification in hardware even before the packets go anywhere? In general, if someone were to send me UPD packets with invalid checksums over the internet, how far would such packets get? In particular, how likely it is that SRTP

Hi, I''ve been looking at Btrfs and have a couple of naive questions that don''t seem to be answered on the wiki or in the articles I''ve read on the filesystem. First: discovering a file''s checksum value. Here''s the scenario: software is writing some data as a fresh file. This software happens to know (a priori) the checksum of this data; for

Introduce a new Checksums module to handle the check of checksums, moving part of the Sigchecker code to it. Adapt the rest of virt-builder to this new module. --- builder/Makefile.am | 2 ++ builder/builder.ml | 2 +- builder/checksums.ml | 51 +++++++++++++++++++++++++++++++++++++++++++++++++ builder/checksums.mli | 29 ++++++++++++++++++++++++++++ builder/index_parser.ml | 4

When --checksum is used they're calculated in both ends to see if the file should be transfered. This is of course not necessary if the file doesn't exist in the destination. However, the checksum is still calculated by the sender, which is often a very large overhead. Would it be possible to avoid it?

On Fri, 17 Apr 2015 23:45:42 -0400, Kevin Korb wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > So, I am assuming that without --itemize-changes you couldn't tell the > difference between "I am transferring a file" and "I am fixing the > timestamp on a file". > > Even if I am right, you are probably still mis-using --checksum. When

On 6/30/07, Wayne Davison <wayned@samba.org> committed: > Added Files: > checksum-xattr.diff > Log Message: > A simple patch that lets rsync use cached checksum values stored in > each file's extended attributes. A perl script is provided to create > and update the values. Wayne, You should be aware of two drawbacks of caching checksums in xattrs: First,

I've been planning on adding these for years. Maybe it's about time soon. I guess they could be added already to v2.2, but enabled only by a new setting because it requires file format changes that old Dovecots can't then read. I could probably patch v2.1 also so it is able to at least read the new format without failing. For v2.3 this new format could then be made the default. And

Hi, this series adds a basic support for Simple Streams v1.0 metadata files. This makes it possible to create a repository .conf files with [cirros] uri=http://download.cirros-cloud.net format=simplestreams to read the latest version of each CirrOS image. TODO items: - a bit more testing: listing and creating images works, so the current metadata is correct - handle revisions, so newer

2007/10/19, Josh Coalson <xflac@yahoo.com>: > > --- Harry Sack <tranzedude@gmail.com> wrote: > > hi > > > > here some questions about the md5 checksum: > > > > - what happens when the md5 checksum of the decoded audio is > > different > > of the internally stored checksum due to file corruption ? Will > > playing/decoding still be

My understanding is that if I "zfs set checksum=<different>" to change the algorithm that this will change the checksum algorithm for all FUTURE data blocks written, but does not in any way change the checksum for previously written data blocks. I need to corroborate this understanding. Could someone please point me to a document that states this? I have searched and searched

I chose rsync over diff -r because diff -r is a binary comparison and it takes longer than creating a checksum. Isn't that correct? I did not understand this: > Rsync isn't even smart enough to not bother checksumming things that don't even have a comparison file. --checksum seems to work as you say even in --dry-run mode. At least it takes a lot of time, which should be a good

I want to use rsync to diff two folders (with checksum) by using dry-run and itemize changes like this: rsync -rni --checksum /dir1/ /dir2/> ~/Desktop/diff.log However, I read that in --dry-run rsync wont do checksums. Is this true? If it is, is there a way to force checksums i dry-run mode?

On Fri, 17 Apr 2015 21:27:56 -0400, Kevin Korb wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Any time rsync wants to do something to a file you don't think it should > be see what --itemize-changes says about it. In fact, -v is almost > entirely useless without --itemize-changes. In fact, if I was in charge > I would make -v include --itemize-changes.