Closed tazerdev closed 4 years ago
This seems to come from the fomantic-ui build process, but I have no clue where it happens, that stack trace does not reveal much. Pretty certain this is not something we ourselves can fix (except by vendoring the built fomantic files again).
Actually it's from here. v8flags
is coming as a indirect dependency of fomantic-ui
└─┬ fomantic-ui@2.8.5
└─┬ gulp@4.0.2
└─┬ gulp-cli@2.2.1
└── v8flags@3.2.0
Given that MD5 crypto is probably still pretty commonplace, I expect this may not be the only such issue. Would suggest you file an issue at v8flags and see how it goes.
@silverwind You're correct. I modified the v8flags module to use sha256 and encountered failures in the webpack module which uses md4 hashes. Looks like a game of whack-a-mole to get FIPS compliance. I'll have to stick with the 1.11.x branch for now.
In essense, I don't think we can deliver deprecated-crypto-free dependencies and disabling the algorithms seems like a overly strict measure to me. NIST SP 800-131A says:
MD5 and SHA-1 are no longer acceptable where collision resistance is required such as digital signatures.
That important part here is "where collision resistance is required". There are many use cases where collision resistance is irrelevant and those weaker ciphers do sometimes offer a performance benefit too.
In the case of v8flags
, MD5 seems to be only used as a cache key, so it can probably be updated but other cases might not be so easy.
Just use https://dl.gitea.io/gitea/1.12/gitea-src-1.12.tar.gz for this as it already contains precompiled frontend code and you need to do only:
CGO_ENABLED=1 TAGS='bindata sqlite sqlite_unlock_notify' make generate backend
Indeed, that's also an option to skip the JS build. Unlike Node.js, I assume Go does not have a FIPS-compliant build or it would run into similar issues 😉
@silverwind Redhat does offer a FIPS aware golang.
@lafriks What's the difference between your link and the git repo? I can successfully complete the following from git:
git clone https://github.com/go-gitea/gitea.git --branch v1.12.0-rc2 --depth=1
cd gitea
CGO_ENABLED=1 TAGS='bindata sqlite sqlite_unlock_notify' make generate backend
I guess the ultimate issue is in upstream dependencies which gitea isn't responsible for. Is it a worthwhile venture to vet all the dependencies for FIPS compliance? That's a question I can't answer.
I guess FIPS-compliant golang (as opposed to node) did not disable MD5 because there sure is usage in the go dependencies:
$ grep -r crypto/md5 vendor
vendor/strk.kbt.io/projects/go/libravatar/libravatar.go: "crypto/md5"
vendor/gitea.com/macaron/cache/file.go: "crypto/md5"
vendor/xorm.io/xorm/caches/encode.go: "crypto/md5"
vendor/golang.org/x/crypto/openpgp/packet/public_key_v3.go: "crypto/md5"
vendor/golang.org/x/crypto/ssh/keys.go: "crypto/md5"
vendor/golang.org/x/tools/internal/imports/zstdlib.go: "crypto/md5": []string{
vendor/github.com/denisenkom/go-mssqldb/ntlm.go: "crypto/md5"
vendor/github.com/pquerna/otp/otp.go: "crypto/md5"
vendor/github.com/keybase/go-crypto/openpgp/packet/public_key_v3.go: "crypto/md5"
vendor/github.com/lib/pq/conn.go: "crypto/md5"
vendor/github.com/satori/go.uuid/generator.go: "crypto/md5"
vendor/github.com/issue9/identicon/identicon.go: "crypto/md5"
vendor/github.com/couchbase/vellum/levenshtein/parametric_dfa.go: "crypto/md5"
I think it's ultimately a futile effort to chase all dependencies to remove MD5/SHA1 usage. It might just not be possible in all cases, and it's often unwarranted to change them when no strong collision resistance is needed.
The src
tarballs should be pretty much identical to git except they are created after node_modules
is installed. See here.
@tazerdev they contain already built javascript and css files in public folder (it's done in our build system before packaging) and does not need nodejs/npm on system but only golang to build
I'm more concerned about non-checksum/fingerprinting activities. As an example, I believe vendor/github.com/lib/pq/conn.go
is using md5 for password encryption but I'm not sure how, or if, gitea actually uses that. I'm not actively utilizing local users after the initial deployment so that particular issue doesn't affect me. I'm also not using the built-in SSH server.
Despite the build errors, I don't think fingerprinting files with md5 is an issue so make generate backend
should be sufficient for my purposes. That will ensure go's crypt calls go through OpenSSL instead of its own internal libraries.
If there's anything you'd like me to do or test, please let me know. Otherwise you can feel free to close the ticket. I do appreciate the time and feedback you've provided.
[x]
):Description
I am unable to build the 1.12.0 branch on a FIPS enabled system. The 1.10.x and 1.11.x branches do build successfully on a FIPS enabled system.
Steps to Reproduce
Perform a git clone:
Build with standard options:
Relevant Console Output
Clone step:
Build step: