~bigbes/sr-ht-compare · issues

te20ut2dj3im1jg5p0edo7ddsuir4lf3 · 2 rows

idcontent_hashtitledescriptiondesignacceptance_criterianotesstatuspriorityissue_typeassigneeestimated_minutescreated_atcreated_byownerupdated_atclosed_atclosed_by_sessionexternal_refspec_idcompaction_levelcompacted_atcompacted_at_commitoriginal_sizesenderephemeralwisp_typepinnedis_templatemol_typework_typesource_systemmetadatasource_repoclose_reasonevent_kindactortargetpayloadawait_typeawait_idtimeout_nswaitershook_beadrole_beadagent_statelast_activityrole_typerigdue_atdefer_untilno_historystarted_atis_blocked
sr-ht-compare-4yv3a6f90aef7850f81dba8c5e2c73048f090739410fbe0de7bed713ed762731d1dMake sourcehut-compare/Makefile's css recipe portable off GNU sha256sumWhat is wrong: the css recipe in sourcehut-compare/Makefile ends with 'mv web/static/main.min.css web/static/main.min.$$(sha256sum ... | cut -c1-8).css'. On a machine without GNU coreutils, sha256sum does not exist, the command substitution yields empty, and mv produces web/static/main.min..css. This affects six Makefiles: sourcehut-{artifacts,compare,coverage,dolt,specs,tokens}/Makefile. Why it matters: that filename does not match main.min.*.css, so assets.Resolve answers "" and every page renders unstyled, with no error anywhere (set -e does not catch a failure inside $$( )). Compounded by D09 (compare tracks the old build artefact) and the compare/dolt/specs/artifacts gap in check-version/check-embedded-css (D12). Correct variant: repo/path sourcehut-bench/Makefile and sourcehut-curator/Makefile, which define 'SHA256SUM ?= sha256sum' and use $(SHA256SUM), with a comment naming 'make SHA256SUM="shasum -a 256" css' as the macOS invocation. Fix: add 'SHA256SUM ?= sha256sum' to sourcehut-compare/Makefile and substitute $(SHA256SUM) for the raw sha256sum call in the css recipe. Audit: D08 (cross-repo audit, 2026-08-17)open1bugNULLNULL2026-08-17T21:36:10Zbigbesbigbes@gmail.com2026-08-17T21:36:10ZNULLNULL0NULLNULLNULL000�{}0NULLNULLNULL0NULL0
sr-ht-compare-g779de449836d2118c925ba7fecbe77c2b5528f3b24fcc0d83cbc879606e52a930eBump gqlparser/gqlgen off the GO-2024-2920 floor in compare/go.modWhat is wrong: sourcehut-compare/go.mod pins github.com/vektah/gqlparser/v2 v2.5.8 and github.com/99designs/gqlgen v0.17.36. gqlparser v2.5.8 is below the fix for GO-2024-2920 (a DoS in parseDirectives), which landed in v2.5.14. Five modules share this stale pin: sourcehut-specs/go.mod, sourcehut-compare/go.mod, sourcehut-tokens/go.mod, sr-ht-core/go.mod, sr-ht-ecore/go.mod. Why it matters: sr-ht-core and sr-ht-ecore are libraries that compare depends on, so their floor becomes compare's floor regardless of whether compare's own /query path requires a credential first. Correct variant: gqlparser/v2 v2.5.36 + gqlgen v0.17.94, already in use by sourcehut-{artifacts,bench,coverage,curator,dolt}, thistle, sr-ht-api and sourcehut-federation (repo/path: sourcehut-bench/go.mod as a reference). Fix: bump sr-ht-core and sr-ht-ecore to gqlparser/v2@v2.5.36 + gqlgen@v0.17.94 first, then run 'go get github.com/vektah/gqlparser/v2@v2.5.36 github.com/99designs/gqlgen@v0.17.94' in sourcehut-compare/go.mod and re-run go mod tidy. Audit: D06 (cross-repo audit, 2026-08-17)open0bugNULLNULL2026-08-17T21:36:09Zbigbesbigbes@gmail.com2026-08-17T21:36:09ZNULLNULL0NULLNULLNULL000�{}0NULLNULLNULL0NULL0