Add Gitember Git GUI client

[iazarny]

Changes

Two files added

• data/guis/gitember.yml
• static/images/guis/gitember@2x.png

which are describes Gitember Git GUI client

Context

Gitember Git GUI client

[dscho]

I did a code review and found something that I think is a showstopper.

In GitRepoService.java, inside configureTransportCommand, whenever the remote URL starts with https, the app does this:

StoredConfig fbcOrig = SystemReader.getInstance().getUserConfig();
fbcOrig.setBoolean(Const.Config.HTTP, null, Const.Config.SLL_VERIFY, false);
fbcOrig.save();

This disables TLS certificate verification in the user's global JGit config, and because save() is called, the setting persists after Gitember exits. That opens the door to man-in-the-middle attacks on all subsequent HTTPS Git operations, even from the command line. I cannot recommend a tool that does this.

Beyond that, there are a few other concerns. The "secret leak detection" feature (advertised in v3.1) is partially broken: the LlmSecretDetector compares the type field against "CRITICAL" but the prompt defines types as SECRET, TOKEN, API_KEY, etc., so almost all findings are silently discarded. And the EntropyDetector has its scan loop commented out entirely. The regex-based ValuePatternDetector still catches common patterns, but the false sense of security from the broken parts is concerning.

The app also auto-downloads Ollama from https://github.com/ollama/ollama/releases/latest/download/ without verifying a checksum or pinning a version, then marks the binary executable and starts it. This is opt-in (the user triggers it from settings), but it is still a real concern.

Credentials (passwords, tokens, key passphrases) are stored in ~/.gitember/gitember2.json using AES with a key derived from user.name + user.home -- not the OS keychain. The legacy decryption path uses a hardcoded key ("0123456789fast11").

I should also mention: the license field in the YAML says "GNU", which is ambiguous. The repo has both a LICENSE-Gnu-3.0.txt and a LICENSE-Apache-2.0.txt. It should be clarified which one governs the application.

I appreciate the long development history (the repo goes back to 2016) and the Apple notarization, but the sslVerify issue alone means I would not be comfortable listing this on git-scm.com as-is.