| Age | Commit message (Collapse) | Author |
|---|
|
docs: fix simple typo, embeded -> embedded
|
|
There is a small typo in lib/sha1.c.
Should read `embedded` rather than `embeded`.
|
|
|
|
HP-UX is not properly detected and classified as little endian. Add test macro
for HP-UX to make it big endian.
|
|
|
|
|
|
Big Endian Detection: Add a whitelist of always BE OSs
|
|
Hopefully fix the issue with AIX falling through this detection logic
and being detected as Little Endian reported on the Git mailing list,
see
https://public-inbox.org/git/20180729200623.GF945730@genre.crustytoothpaste.net/
Attempt to solve this by extending the existing fallback we have for
detecting always Big Endian processors to also detecting always Big
Endian OSs. See the public-inbox link in the comment I'm adding for
why this should work.
I have not tested this myself, since I have no access to AIX. I'll be
pointing Michael Felt to the relevant MR so he can test it before this
is merged.
|
|
This was originally fixed in git.git's copy of the library in 6412757514 ("Spelling fixes", 2017-06-25).
|
|
Fix endian detection logic for Sparc, little endian BSD etc.
|
|
the _BIG_ENDIAN macro on NetBSD 9 and Solaris 9 are already visible here.
but it's because <sys/types.h> is included indirectly via <stdlib.h>
or <memory.h>. that's fragile against changes in those headers.
pointed out by obache-san
|
|
In 33a694a ("Fix issues with a big endian platform", 2017-05-15) *BSD
and newlib was broken because _BIG_ENDIAN is always defined, even on
little-endian platforms.
To fix this we need to also check the single-underscore version of
BIG_ENDIAN & LITTLE_ENDIAN, but only do this if _LITTLE_ENDIAN is also
defined. This makes sure that on Solaris we don't break where
_BIG_ENDIAN is simply defined, not to any value (but _LITTLE_ENDIAN
won't be). See
http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/isa_defs.h#397
The https://github.com/cr-marcstevens/sha1collisiondetection/pull/34
pull request has a lot more details on the various issues involved,
things that were tried (and not tried) etc.
[Commit message & rebase by Ævar]
|
|
|
|
Fix BigEndian detection in a more robust way.
|
|
As discussed in some detail on the Git mailing
list (87tw31jmau.fsf@gmail.com & 87r2y5jkb6.fsf@gmail.com) we don't
actually need to check _BIG_ENDIAN at all, because this is covered by
the __sparc check earlier on.
Thus this makes the whole logic:
- Check settings modern (post-2011) GCC & clang export
- Check glibc settings exported since forever (1993-ish)
- Check a long list of processors known to be big-endian
- If any of the above say we're big endian...
- ...otherwise little-endian
|
|
My recent db62148 ("Correctly detect Big Endian on Solaris",
2017-06-26) was faulty as reported in
https://public-inbox.org/git/CAKKM46tHq13XiW5C8sux3=PZ1VHSu_npG8ExfWwcPD7rkZkyRQ@mail.gmail.com/T/#u
As far as I can tell most of the logic we have to detect Big Endian
already is somewhat cargo-culted, e.g. checking multiple underbar
versions of the same define, even though I can find no evidence that
e.g. glibc ever exported all those variants.
Rewrite it to check an exhaustive list of things we *know* actually
exists. It's still possible that this will give us a false positive
when it falls through to checking if _BIG_ENDIAN is defined, but at
least it'll be on some really obscure platform.
While I'm at it, factor out the Intel detection we already do for
SHA1DC_ALLOW_UNALIGNED_ACCESS into its own macro so we can use it as a
paranoid last resort for "not Big Endian here".
This is known to now pass on two different SunOS 11.3 sun4v sparc
machines.
|
|
The current code fails to detect Big Endian SPARC on Solaris. The
reason for this is that __BYTE_ORDER is defined on Solaris, however
because we're trying to avoid a case on Linux where __BYTE_ORDER and
__BIG_ENDIAN will always be defined, we're only defining
SHA1DC_BIGENDIAN if the two are equivalent.
That's not the case on Solaris, and tweaking this code easily lands
you in the case where you ruin either Linux or Solaris, because on
Linux those two are always defined.
There's probably some really tricky middle ground here that would
auto-detect this without checking the OS, e.g. I know _BIG_ENDIAN is
defined on Solaris, but probably not on Linux (but all versions? who
knows?). Liam R. Howlett <Liam.Howlett@oracle.com> reports that this
works, and it works for me too on Linux x86_64:
diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c
index facea1bb5..8c95c64ce 100644
--- a/sha1dc/sha1.c
+++ b/sha1dc/sha1.c
@@ -38,7 +38,8 @@
#if (defined(_BYTE_ORDER) || defined(__BYTE_ORDER) || defined(__BYTE_ORDER__))
-#if ((defined(_BYTE_ORDER) && (_BYTE_ORDER == _BIG_ENDIAN)) || \
+#if ((defined(__BYTE_ORDER__) && defined(_BIG_ENDIAN)) || \
+ (defined(_BYTE_ORDER) && defined(_BIG_ENDIAN) ) || \
(defined(__BYTE_ORDER) && (__BYTE_ORDER == __BIG_ENDIAN)) || \
(defined(__BYTE_ORDER__) && (__BYTE_ORDER__ == __BIG_ENDIAN__)) )
#define SHA1DC_BIGENDIAN
As an aside, this whole thing looks like it may have worked on Solaris
before a24eef5 ("rewrote Endianness selection", 2017-05-29), but of
course other stuff was broken before then.
Let's just take the easy way out here and manually detect Solaris,
they're unlikely to add another Big Endian processor any time soon,
and then the rest of this logic can stop worrying about being paranoid
about Solaris.
|
|
Fix for endian check on sparc processors.
|
|
|
|
|
|
This is the feedback I left on pull request #30[1] turned into a
patch.
1. https://github.com/cr-marcstevens/sha1collisiondetection/pull/30
|
|
The entirety of the rest of the file uses 8-width tabs, but this[1]
change added 4-width spaces.
1. db45d67 ("Fix performance regression on processors that allow
unaligned memory access. (#30)", 2017-05-18)
|
|
|
|
This allows for doing -DSHA1DC_FORCE_UNALIGNED_ACCESS on a
platform/CPU that's not listed here, since the default is to fall back
to aligned access unless except on a whitelist of CPUs.
It would be nice e.g. for the git project if someone running on such a
platform didn't have to monkeypatch the code, instead they can just
provide a -DSHA1DC_FORCE_UNALIGNED_ACCESS argument
|
|
This all turns up warnings under "git am". These tend to raise
complaints on the git mailing list when they need to apply patches, so
give people less of a reason to complain.
|
|
This is a hack so that I can run "make" cleanly in git.git. This is
really a wart around there being no easy way to have tracked
.gitignore changes to submodules.
You can hack e.g. .git/modules/sha1collisiondetection/info/exclude,
but that's not under source control, and thus needs to be done by the
Makefile.
This is an easy workaround that won't show the module dirty everytime
"make" is run, while we think about some longer-term fix for this.
|
|
|
|
This introduces no functional changes, but allows the lib/ code to be
used as-is in other programs without patching these files directly,
instead those programs can define a few variables to inject their
custom code into this code.
With these changes the git project can use this code without any
modifications to the upstream code. The corresponding git mailing list
thread discussing that is at "[PATCH/RFC 0/3] Use
sha1collisiondetection as a submodule"[1]. The defines used by git in
that patch are:
-DSHA1DC_NO_STANDARD_INCLUDES \
-DSHA1DC_INIT_SAFE_HASH_DEFAULT=0 \
-DSHA1DC_CUSTOM_INCLUDE_SHA1_C="\"cache.h\"" \
-DSHA1DC_CUSTOM_TRAILING_INCLUDE_SHA1_C="\"../sha1dc_git.c\"" \
-DSHA1DC_CUSTOM_TRAILING_INCLUDE_SHA1_H="\"../sha1dc_git.h\"" \
-DSHA1DC_CUSTOM_INCLUDE_UBC_CHECK_C="\"git-compat-util.h\""
I.e. all of these except SHA1DC_CUSTOM_TRAILING_INCLUDE_UBC_CHECK_[CH]
are used by git. I've merely added those for completeness since other
projects doing similar customization might want to use them.
The monkeypatches the git project was using previously were:
- https://github.com/git/git/commit/45a574eec8
- https://github.com/git/git/commit/c0c20060af
- https://github.com/git/git/commit/8325e43b82
The entire paragraph being added to the README file was authored by
Dan Shumow. See
https://github.com/cr-marcstevens/sha1collisiondetection/pull/31.
1. <20170517113824.31700-1-avarab@gmail.com>
(https://public-inbox.org/git/20170517113824.31700-1-avarab@gmail.com/)
|
|
(#30)
|
|
|
|
some IO improvements
|
|
|
|
|
|
|
|
Build/vs
|
|
|
|
|
|
* Protect against outside definitions of SHA1DC_BIGENDIAN, one can fo…
|
|
endianness with either SHA1DC_FORCE_BIGENDIAN or SHA1DC_FORCE_LITTLEENDIAN.
* added header guards for lib/sha1.h
|
|
Feature/performance
|
|
|
|
|
|
|
|
|
|
main.c: use API to determine if collision was found
|
|
based on preprocessor macros.
|
|
|
|
|
|
* Re-add lost code from merge
|
|
|
