Don't specify the password on the command line #22
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://www.netmeister.org/blog/passing-passwords.html has a decent overview of the security issues with that. Since this is interactive, getting curl to prompt for the password is probably the easiest alternative. From https://curl.se/docs/manpage.html#-u > If you simply specify the username, curl prompts for a password. I don't have an easy way to test the actual command in this doc, but the flag does seem to behave as documented at least: ``` $ curl --user [email protected] https://google.com Enter host password for user '[email protected]' ``` Fixes gitgitgadget/gitgitgadget#1843
|
Is this a bug in the workflow, or am I supposed to do something? I do have "allow edits by maintainers" checked. |
This is something I wasn't sure whether it could work, see "Verify that the PR workflow succeeds to push updates even for PRs that originated from a fork" in #21 (comment). |
|
Let me see what I can do about this. |
dscho
force-pushed
the
cmdline-no-secrets
branch
7 times, most recently
from
fc9661e to
16172c3
Compare
When the HTML page(s) are not up to date, the PR build re-generates them, commits the result and wants to push it to the branch. However, this only works if the PR branch and the target branch are in the same repository. Otherwise the workflow run's `GITHUB_TOKEN` lacks write permission, even if the PR author gave permission to the maintainers to push to that branch. Let's fall back to doing the next best thing and publish a Git bundle, and provide instructions how to fetch from them and update the PR with those changes. Signed-off-by: Johannes Schindelin <[email protected]>
dscho
force-pushed
the
cmdline-no-secrets
branch
from
16172c3 to
3bf1328
Compare
|
There. 3rd times 3rd time is a charm:
For the record: I changed the PR build so that it no longer tries to push to the branch (unless the PR originates from the same repository) but instead publishes a Git bundle and describes how to pull from said bundle and then update the PR, which is what I did and therefore the PR build passed successfully. Thank you @dseomn for your patience and for the contribution! |
Merged
dscho
added a commit
that referenced
this pull request
Mar 8, 2025
Rather than trying to continue running something home-grown, let's switch to a proper static site generator. This partially addresses some concerns I [raised after integrating the wiki pages](#21 (comment)) and the problems we ran into when [the workflow to update the HTML pages failed in a PR by a contributor](#22 (comment)): While it still does not offer convenient before/after views, it at least allows to preview the changes in a fork, just like this here PR can be previewed at https://dscho.github.io/gitgitgadget.github.io/ So why even bother with a powerful site generator like Hugo for something as small as GitGitGadget's home page? Well, here are a couple of reasons: - As you can see https://dscho.github.io/gitgitgadget.github.io/architecture, it re-adds the syntax highlighting in code blocks that were lost in the transition away from the wiki. - It will make auto-generating a navigation bar (or a central index page) much easier. - It will make it easier to maintain a unified look-and-feel, e.g. when adding something like an "Edit on GitHub" button. - It should make it somewhat easier to make the site [responsive](#19) because of a much more standard way to build the site. - The migration of the wiki pages was meant as a blueprint I could follow in Git for Windows, where I want to stop wasting my time battling spam and vandalism, and any subsequent work over here that can help with that can increase the synergy between both projects.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://www.netmeister.org/blog/passing-passwords.html has a decent overview of the security issues with that.
Since this is interactive, getting curl to prompt for the password is probably the easiest alternative. From
https://curl.se/docs/manpage.html#-u
I don't have an easy way to test the actual command in this doc, but the flag does seem to behave as documented at least:
Fixes gitgitgadget/gitgitgadget#1843