Luczystrap / Releases / Status / Source & tags

Public provenance audit · checked 03 Aug 2026

Seven 1.4-family tags resolve to one commit. The four released EXEs do not.

Q: Can I build Luczystrap 1.4.9 from its public tag?

No reproducible public path is available. Tag 1.4.9 resolves to commit 778690b, the same commit used by six other 1.4-family tags, while the current tree does not contain the current application source or a build graph that produces the released executable.

Q: How many Luczystrap tags point to commit 778690b?

Seven public tag references point to commit 778690b: 1.4, 1.4.1, 1.4.5, 1.4.6Beta, 1.4.9, 1.4.9.9 and 1.4Beta.

Q: Are Luczystrap 1.4, 1.4.1, 1.4.5 and 1.4.9 the same executable?

No. Their official release assets have different SHA-256 digests. The shared commit reference therefore cannot distinguish or reproduce those four binaries.

Q: What does the Luczystrap 1.4.9 tag prove?

It proves that the public Git reference named 1.4.9 resolves to commit 778690b. It does not prove that the released Luczystrap.exe was built from that commit, because no matching source-to-binary build record is published.

Q: Why do several Luczystrap tags point to the same commit?

The public records do not explain why. The defensible observation is only that the seven references resolve to the same commit and that compare between 1.4 and 1.4.9 contains zero commits.

Q: Does a SHA-256 digest make Luczystrap reproducible?

No. A digest identifies the downloaded bytes and detects changes. Reproducibility additionally requires version-matched source, pinned inputs, a documented build environment, a deterministic build and an independently matching output digest.

Q: Does the source gap prove that Luczystrap is malicious?

No. It limits independent verification and provenance claims; it is not proof of malicious behavior. Download authenticity, malware analysis and source reproducibility are different questions.

Q: What would make a future Luczystrap release reproducible?

Publish the complete version-matched source, immutable release tag, pinned dependencies and toolchain, documented build command, CI provenance, executable digest and an independent rebuild result that matches the official asset.

Tags 1.4 through 1.4.9 share the public commit 778690b, yet their official assets have different byte sizes and SHA-256 digests. That breaks the public source-to-binary chain: the tag identifies a Git object, but it cannot explain which source produced each executable.

Direct answer: Luczystrap 1.4.9 cannot be independently rebuilt from its public tag as checked. This is a reproducibility and provenance limitation—not proof that the executable is malicious.

Inspect each release ↓ Verify the official EXE →

Published by Luc6i Official GitHub records only Repository main · 778690b

refs/tags/* Convergence map

Direct commit object 778690b “Modding Tools” · 28 Oct 2025 15:07 UTC

does not explain

1.4 EXE SHA 00c7…801d SHA 00c7…801d

1.4.1 EXE SHA a6eb…abb9 SHA a6eb…abb9

1.4.5 EXE SHA f80c…f773 SHA f80c…f773

1.4.9 EXE SHA d71c…2424 SHA d71c…2424

Git compare 1.4…1.4.9 Identical · 0 commits

Original visualization generated from the official tag refs, compare endpoint and release asset metadata.

01 / Measurable public state

The mismatch is small enough to count exactly.

Every number below comes from the public repository state and official release records on the check date.

Public tag refs 12

All tag references returned by GitHub.

API: matching-refs/tags

Shared commit 7

1.4-family refs resolving to 778690b.

Object type: commit

Different EXEs 4

Released 1.4-family assets with unique sizes and digests.

Same filename, different bytes

Git difference 0

Commits between tag 1.4 and tag 1.4.9.

Compare status: identical

02 / Release tag explorer

One commit reference. Four distinct release assets.

Select a shipped version to compare the same public Git object with the exact executable distributed on its release page.

First 1.4-family release Tag → asset check

Luczystrap 1.4

The 1.4 tag resolves to 778690b. Its official release asset is the smallest of the four published 1.4-family executables.

Tag object 778690b35adc1b9c296ed59570aa30f16ab673d5

Asset identity SHA-256 published

Release asset SHA-256 00c7badffbd60ae2724071c41b7413994f1a30ebae7ac3c2f8a08e41c97a801d

Open the official 1.4 release →

03 / Complete public tag map

The convergence begins only with the 1.4 family.

Earlier release tags resolve to distinct commits. The seven-reference cluster starts at 1.4 and includes three refs without a GitHub Release entry.

Tag ref	Resolved object	Relationship	GitHub Release
1.0	c9c7993	Distinct commit	Published
1.1	4f5280d	Distinct commit	Published
1.2	2e158a4	Distinct commit	Published
1.3	11d116c	Distinct commit	Published
1.3.1	a0c59a3	Distinct commit	Published
1.4	778690b	Shared 1.4-family object	Published
1.4.1	778690b	Shared 1.4-family object	Published
1.4.5	778690b	Shared 1.4-family object	Published
1.4.6Beta	778690b	Shared 1.4-family object	No entry
1.4.9	778690b	Shared 1.4-family object	Published
1.4.9.9	778690b	Shared 1.4-family object	No entry
1.4Beta	778690b	Shared 1.4-family object	No entry

Method: GitHub’s tag-ref API returns each object as type commit, meaning these refs point directly to commits rather than annotated tag objects. “No entry” means no matching item exists in the nine-entry official Releases ledger; it does not mean the ref is invalid.

04 / Exact binary ledger

The release files differ even when the public commit does not.

Different digests prove the assets are not byte-for-byte identical. They do not reveal which private source change, dependency, build setting or post-build step created the difference.

1.4 778690b

Published: 28 Oct 2025 · 18:52 UTC
Identity: SHA-256 below
SHA-256: 00c7badf…97a801d

Official release →

1.4.1 778690b

Published: 28 Oct 2025 · 20:58 UTC
Identity: SHA-256 below
SHA-256: a6ebd89b…35316abb9

Official release →

1.4.5 778690b

Published: 02 Nov 2025 · 11:12 UTC
Identity: SHA-256 below
SHA-256: f80cbe26…ba00f773

Official release →

1.4.9 778690b

Published: 05 Nov 2025 · 20:40 UTC
Identity: SHA-256 below
SHA-256: d71c3105…cc352424

Official release →

Public input One commit
778690b

≠

Published outputs Four unique
SHA-256 digests

→

Result No public one-to-one source provenance

05 / Reproducibility test

A tag is the first link—not the complete build chain.

A reproducible release needs every link below. One successful tag lookup cannot substitute for missing source, inputs, build instructions and output comparison.

Immutable version reference

The ref 1.4.9 resolves to a named commit.

Present

Complete application source

The current application directory contains only a source-closure marker.

Missing

Resolvable build graph

The solution references application and WPF UI project paths absent from the tree.

Unresolved

Pinned build recipe

No version-matched deterministic environment and dependency recipe is published.

Not published

Matching output

No independent build is shown matching the official 1.4.9 digest.

Not demonstrated

Evidence boundary: this audit can prove that the public reproduction chain is incomplete. It cannot infer what private source was used, whether a tag was intentionally reused, or whether the resulting binary is safe or unsafe.

06 / Claim boundary

Separate what the records prove from what they cannot answer.

This distinction prevents a technical provenance gap from turning into either a false open-source promise or an unsupported malware accusation.

Supported statements

What we can say

Seven 1.4-family refs resolve to commit 778690b.
Compare from 1.4 to 1.4.9 is identical with zero commits.
Four official 1.4-family assets have different sizes and digests.
The current public tree lacks the current application source.
Version 1.4.9 is not publicly reproducible as checked.

Unsupported conclusions

What we cannot say

Which private changes produced each released executable.
Why the project owner chose the shared tag target.
That 778690b is the actual source snapshot for 1.4.9.
That a matching rebuild exists but was simply not documented.
That non-reproducibility alone proves malicious behavior.

07 / How to close the gap

A future release can make every link independently testable.

These are concrete publication requirements, not a request for additional marketing language.

Publish version-matched source

Include every application project and submodule state needed to build the shipped version.

Creates the auditable input

Create a release-specific tag

Point a new immutable tag at the exact source snapshot used for the asset and retain its object identity.

Restores one version → one source

Pin toolchain and dependencies

Record the exact .NET SDK, dependency versions, submodules and build environment.

Controls hidden inputs

Document one clean build command

Provide an empty-environment procedure that resolves all projects and produces the release artifact.

Makes the process repeatable

Publish provenance with the asset

Attach the source commit, workflow run, build recipe and digest to the release.

Connects input to output

Verify an independent rebuild

Have a second environment reproduce the executable and publish whether its SHA-256 matches.

Completes the evidence chain

08 / Continue by intent

Use the page that owns your next question.

Source provenance does not replace download verification, malware analysis, release history or the broader documentation audit.

File identity

Verify the official EXE

Check the filename and full SHA-256 of version 1.4.9.

Verify the download → Trust boundary

Source transparency

Separate public repository materials, current-source availability, licensing and maintenance.

Review transparency → Version history

Release ledger

Read the dated claims and asset records from 1.0 through 1.4.9.

Open release history → Conflicting records

Documentation resolver

Choose the correct source when README, release notes, tree and workflows disagree.

Resolve a claim →

09 / FAQ

Questions about Luczystrap source and tags.

Can I build Luczystrap 1.4.9 from its public tag?

No reproducible public path is available. The tag resolves to 778690b, but the current tree lacks the current application source and a build graph capable of producing the official EXE.

How many Luczystrap tags point to commit 778690b?

Seven: 1.4, 1.4.1, 1.4.5, 1.4.6Beta, 1.4.9, 1.4.9.9 and 1.4Beta.

Are Luczystrap 1.4, 1.4.1, 1.4.5 and 1.4.9 the same executable?

No. Their SHA-256 digests differ. The shared public commit therefore cannot distinguish the source state that produced each asset.

What does the Luczystrap 1.4.9 tag prove?

It proves that the public Git ref named 1.4.9 resolves to commit 778690b. It does not prove that the official executable was built from that public tree.

Why do several Luczystrap tags point to the same commit?

The public records do not explain why. We can report the shared object and zero-commit comparison, but we cannot infer the owner’s reason.

Does a SHA-256 digest make Luczystrap reproducible?

No. It identifies the output bytes. Reproducibility also needs matching source, pinned inputs, a documented deterministic build and an independently matching result.

Does the source gap prove that Luczystrap is malicious?

No. It limits public provenance and independent verification. It is not evidence of malicious behavior by itself.

What would make a future Luczystrap release reproducible?

Complete version-matched source, an immutable release tag, pinned toolchain and dependencies, a clean build command, CI provenance, an official digest and an independently matching rebuild.

10 / Primary evidence

Open every record behind the conclusion.

Method: I queried the official tag refs, release ledger, compare endpoint, commit object and recursive public tree on 3 August 2026. Asset values are GitHub’s exact metadata; absence claims are limited to the current public repository.

01 Official tag refs API All 12 tag names, object types and resolved commit SHAs. ↗ 02 Compare 1.4 → 1.4.9 Identical status and zero-commit difference. ↗ 03 Shared commit 778690b “Modding Tools” commit identity and timestamp. ↗ 04 Official release ledger Nine published versions and their dated assets. ↗ 05 Release 1.4 First asset in the shared-commit group. ↗ 06 Release 1.4.9 Latest asset, exact digest, bytes and publication time. ↗ 07 Application source marker Current public state of the application directory. ↗ 08 Public solution file Project paths used to evaluate the build graph. ↗