profile
viewpoint
Ulrich Kunitz ulikunitz Germany Go developer interested in compression; DevOps manager for identity & authentication

ulikunitz/xz 358

Pure golang package for reading and writing xz-compressed files

ulikunitz/unixtime 8

Go Package providing Unix time conversions

ulikunitz/damm 3

Golang package for computing a decimal check digit

ulikunitz/xio 1

Go package providing a wrapper for a Writer supporting WriteString and WriteByte.

ulikunitz/fiboheap 0

Go implementation of Fibonacci Heaps

push eventulikunitz/ulikunitz.github.io

Ulrich Kunitz

commit sha 07951416bf47dc87be5b99bb07b0b7a6253a441c

Use publishdir docs as required for Github pages.

view details

push time in 11 minutes

push eventulikunitz/ulikunitz.github.io

Ulrich Kunitz

commit sha dc466c0aa83db9cda883358ac50257df1740a12e

Changed to hugo site generator.

view details

push time in 15 minutes

push eventulikunitz/ulikunitz.github.io

Ulrich Kunitz

commit sha a1bf16af55f86e826e3387284aeab1ff531f7f7b

No e-mail

view details

push time in 10 hours

push eventulikunitz/ulikunitz.github.io

push time in 10 hours

push eventulikunitz/ulikunitz.github.io

Ulrich Kunitz

commit sha 3656bd535f17b51b8dcf9d70d1ed65e2496c1e65

Set theme jekyll-theme-hacker

view details

push time in 10 hours

push eventulikunitz/ulikunitz.github.io

Ulrich Kunitz

commit sha edfd096c4cf6c522a676aea3378418f72ec5e198

Set theme jekyll-theme-architect

view details

push time in 10 hours

create barnchulikunitz/ulikunitz.github.io

branch : main

created branch time in 10 hours

created repositoryulikunitz/ulikunitz.github.io

created time in 11 hours

issue commentgolang/go

compress/zlib: NewWriterLevel(&in, zlib.BestCompression) is not good as other lauguages at the same level

If you want the same compression rate as another compression tool, you need to replicate the Lempel-Ziv-Encoder exactly and use the same parameters. So this is actually a request to implement the zlib Lempel-Ziv-Encoder exactly as in zlib.

walter1045

comment created time in 8 days

issue commentgolang/go

crypto/x509: The if's condition checks that err is not nil but returns nil

Comparing marshalBasicConstraints to marshalExtKeyUsage and marshalCertificatePolicies it looks like an error. But I don't think that the error path is reachable, since I don't know how asn1.Marshal should fail.

It is more concerning that the function would encode maxPathLen < -1 and parseBasicConstraintsExtension would parse that without raising an error. Certficate.isValid() would not detect a problem because it does only a check if the value is not negative, but it wouldn't indicate a problem if MaxPathLen is negative.

With a simple test for marshalBasicConstraints I could create following DER value: 30060101ff0201fe, which contains a -2 for pathLen and could parse it with parseBasicConstraintsExtension.

The encoding is in violation of RFC5280 section 4.2.1.9 which defines basic constraints as:

id-ce-basicConstraints OBJECT IDENTIFIER ::=  { id-ce 19 }

   BasicConstraints ::= SEQUENCE {
        cA                      BOOLEAN DEFAULT FALSE,
        pathLenConstraint       INTEGER (0..MAX) OPTIONAL }
tenntenn

comment created time in a month

issue commentgolang/go

regexp and unicode: incorrect General_Category for /u1734

UAX44 contains following statement for 14.0:

The General_Category for U+1734 HANUNOO PAMUDPOD was changed from Mn to Mc, for consistency in treatment with the newly encoded U+1715 TAGALOG PAMUDPOD.

orkvozku

comment created time in a month

issue commentgolang/go

cmd/compile: Get rid of redundant TEST instructions by using the ZF flag of DEC/INC

Are there micro-benchmarks proving this is a speed increase? Chips are doing macro-op and micro-op fusions nowadays. The test and the following jump are very clearly in that territory. You might end-up with smaller binaries, which will help caching and decoding, but no real speed increase on the µOp level.

jake-ciolek

comment created time in a month

issue commentulikunitz/xz

[SECURITY] Implementation of readUvarint vulnerable to CVE-2020-16845

My statement has been wrong, I retract it here. It doesn't add anyway to the discuission.

0xdecaf

comment created time in 3 months

create barnchulikunitz/xz

branch : dev21

created branch time in 3 months

issue commentulikunitz/xz

[SECURITY] Implementation of readUvarint vulnerable to CVE-2020-16845

Just looked in detail to the Red Hat rating, which stated that they use CVSS rating only as guidance, but they are not stating what criteria they are using. I don't support this approach because it makes vulnerability rating arbitrary.

In my professional life we are always reviewing all vulnerabilities in security reports and target to fix all of them and use the rating only for prioritization. Low risk issues might be fixed as part of the normal release cycle. If we exclude a reported vulnerability from fixing it requires a justification that is approved by management.

0xdecaf

comment created time in 3 months

issue commentulikunitz/xz

[SECURITY] Implementation of readUvarint vulnerable to CVE-2020-16845

I have reviewed the rating and I get the same CVSS 3.1 base score 7.5 as the Go CVE, which makes it a high risk vulnerability.

It is clearly a violation of the xz specification section 1.2, which limits the number of supported integer bits. A sufficient large number of input bytes makes this an availability issue with high impact that could be exploited over the network. Infinite input is not required. The CVSS base score for such a vulnerability is 7.5, making it a high risk vulnerability. You might disagree with the CVSS scoring methodology, but it has to be applied here to allow a comparison of vulnerabilities.

The concatenation of empty files is supported by the specification and is therefore supported by the library. If that leads to availability issues it has to be handled by the code using the library, e.g. by limiting the number of input bytes supported. So I don't regard the example as an issue for the library requires fixing.

0xdecaf

comment created time in 3 months

issue commentulikunitz/xz

[SECURITY] Implementation of readUvarint vulnerable to CVE-2020-16845

Many thanks for the input.

It was clearly an issue that had a fix. It was not a statement that there are no other ways to provide input that may consume CPU time or have other negative effects.

I have been new to the vulnerability management in Github and the consequences. The rating was based of the rating of the exact same issue for the Golang library. I will review the rating definition and whether the rating was appropriate for the issue in the context of the xz library. At this time I don't know whether I can change the rating retrospectively, if my review results in a lower rating.

I will also review the example you provided. Should it highlight an issue that is not inherent in the protocol and there is actually a fix, I will create another issue and fix this new issue as well. I'm not sure whether I will create another security vulnerability report for it. Personally I believe that this vulnerability management forces unpaid developers to do compliance work for corporate enterprises. It is still manageable, but I have spent already too much time on the vulnerability management for this relatively simple issue and fix.

0xdecaf

comment created time in 3 months

more