linux packageinfo leaks local sourcedir

[LW-archlinux]

oolite trunk rev 5083ea4 , sourcebuild using aur packaga oolite-git

$ oolite-git.sh packageinfo
{
    title = "Oolite core";
    identifier = "org.oolite.oolite";
<snip>    
    git_remote_url = "/home/panoramix/Downloads/sourcefiles/oolite-git";
<snip>
}
$ 

/home/panoramix/Downloads/sourcefiles/oolite-git is a local cache for downloads used by archlinux makepkg tool .
It should NOT be listed anywhere in oolite info or executable .

I understand oolite can't handle every used packaging tool, a method to set the git_remote_url at build time would suffice to solve this.

[mcarans]

@LW-archlinux I am not sure how to handle this. I want a way to distinguish between builds that were done with a clone of the original Oolite repo and builds done from forks as i don't want to end up wondering why I can't find a commit hash for a build only to find that it wasn't created using the main repo. This is what I have right now:

echo "    git_remote_url = \"$(git config --get remote.origin.url)\";"
echo "    git_commit_hash = \"$(git rev-parse HEAD)\";"

Do you know of any git command that will return the actual repo used without returning that local cache one?

[oocube]

Just guessing:
If the git_remote_url does not qualify as URL, it must be a local path.

If we see that situation, we could use a relative path. We could use the username and hostname and path (to be concise but that would resemble the leak that lw-archlinux is trying to prevent). We could use nothing as well. After all a local build means the files could be tampered, so any 'real' version number might be misleading.

That's where I am quite content to simply stay on the old numbering scheme.

[mcarans]

@LW-archlinux AI suggested the following:

# 1. Get the immediate remote URL (could be a web URL or a local path)
RAW_URL=$(git config --get remote.origin.url)

# 2. Check if the URL is actually a local directory path
if [ -d "$RAW_URL" ]; then
    # If it's a directory, query its internal .git config for the original remote
    # We use || true to prevent the script from crashing if the cache folder is missing/inaccessible
    UPSTREAM_URL=$(git --git-dir="$RAW_URL/.git" config --get remote.origin.url 2>/dev/null)
    
    # If we successfully found an upstream URL inside the cache, use it. 
    # Otherwise, keep the local path as a fallback.
    if [ -not -z "$UPSTREAM_URL" ]; then
        FINAL_URL="$UPSTREAM_URL"
    else
        FINAL_URL="$RAW_URL"
    fi
else
    # It's already a standard web URL (GitHub, GitLab, etc.)
    FINAL_URL="$RAW_URL"
fi

# 3. Output the result in your original formatting
echo "    git_remote_url = \"$FINAL_URL\";"

Please can you tell me if that gives the correct remote url for you.

If that works I would change one thing in the above:

    if [ -not -z "$UPSTREAM_URL" ]; then
        FINAL_URL="$UPSTREAM_URL"
    else
        FINAL_URL="UNKNOWN"
    fi

That way there is no way the local folder can get leaked even if the git --git-dir command fails.

[oocube]

Even if you successfully find the upstream repository and maybe the latest version tag - what do you do with uncommitted changes? With them the version built can contain different code not reflected in the version number.

[LW-archlinux]

/home/panoramix/Downloads/sourcefiles/oolite-git is indeed a local path and as far as git knows it is the remote url..

The contents of that folder are created/managed by archlinux makepkg buildtool using info from the source= array in a PKGBUILD.
https://wiki.archlinux.org/title/PKGBUILD#source for details.

the folder doesn't contain a typical git clone, but a bare clone without a working directory .

stack overflow thread that may be helpful .

[mcarans]

Even if you successfully find the upstream repository and maybe the latest version tag - what do you do with uncommitted changes? With them the version built can contain different code not reflected in the version number.

The meson versioning approach can handle uncommitted changes - see the other issue: #676 (comment)

It is likely simplest to try to use the versioning built into the build system instead of rolling something custom and I could look at that if it is agreed as a way forward.

[oocube]

Thank you for providing the approach to handle local changes. I like the meson way of doing this.
Yet I would not go with custom stuff - we'd loose more features that we can gain, and this development effort should actually go elsewhere into the project.

The intent of the git_remote_url was to have a pointer back to the source code that was getting compiled. Even with AUR builds there must be one such url, even if it is not retrievable by our logic. Would it be feasible to introduce yet another environment variable? If set, use it. If not, calculate the way we already have.

It would allow AUR builds to override our algorithm with a URL they used to clone from.

[mcarans]

The intent of the git_remote_url was to have a pointer back to the source code that was getting compiled. Even with AUR builds there must be one such url, even if it is not retrievable by our logic. Would it be feasible to introduce yet another environment variable? If set, use it. If not, calculate the way we already have.

Yes it would - that's a good idea.

[LW-archlinux]

I verified

https://github.com/OoliteProject/oolite
$ 

works, so the remote url can be retrieved programmatically.

If that is used, overriding the value is not necessary.

Note that a bare clone doesn't have a .git folder , so the --git-dir is slightly different from the code in #677 (comment) .

[mcarans]

I verified

https://github.com/OoliteProject/oolite
$ 

works, so the remote url can be retrieved programmatically.

If that is used, overriding the value is not necessary.

Note that a bare clone doesn't have a .git folder , so the --git-dir is slightly different from the code in #677 (comment) .

What needs to change with the --git-dir for a bare clone? AI suggested something like:

REAL_GIT_DIR=$(cd "$RAW_URL" && git rev-parse --git-dir 2>/dev/null)

git --git-dir="$REAL_GIT_DIR" config --get remote.origin.url

ie.

# 1. Get the immediate remote URL (could be a web URL or a local path)
RAW_URL=$(git config --get remote.origin.url)

# 2. Check if the URL is actually a local directory path
if [ -d "$RAW_URL" ]; then
    # Dynamically find the correct git directory (works for both standard and bare clones)
    RESOLVED_GIT_DIR=$(cd "$RAW_URL" && git rev-parse --git-dir 2>/dev/null)
    
    if [ -n "$RESOLVED_GIT_DIR" ]; then
        # Query the resolved git directory for the original remote
        # We prefix with the path if RESOLVED_GIT_DIR is relative (like ".")
        UPSTREAM_URL=$(git --git-dir="$RAW_URL/$RESOLVED_GIT_DIR" config --get remote.origin.url 2>/dev/null)
    fi
    
    # If we successfully found an upstream URL inside the cache, use it. 
    # Fixed syntax: Changed '-not -z' (invalid bash) to '-n' (not empty).
    if [ -n "$UPSTREAM_URL" ]; then
        FINAL_URL="$UPSTREAM_URL"
    else
        FINAL_URL="UNKNOWN"
    fi
else
    # It's already a standard web URL (GitHub, GitLab, etc.)
    FINAL_URL="$RAW_URL"
fi

# 3. Output the result in your original formatting
echo "    git_remote_url = \"$FINAL_URL\";"

Worked for me with shallow bare clone locally.

[LW-archlinux]

Running git rev-parse --git-dir 2>/dev/null in the directory of a bare clone returns . (a dot) aka the current dir .

I'd code something like this:

If [ -d "RAW_URL ]; then
   If [-d "RAW_URL"/.git ]; then
      RESOLVED_GIT_DIR="$RAW_URL"/.git
   else
     RESOLVED_GIT_DIR="$RAW_URL"
  fi

It does the same but is a lot easier to read for humans and likely less resource intensive as it doesn't need to spawn a subshell
(requiring a subshell is one of the downsides of command substitution) .

Note that I'm not a bash guru and there may be syntax errors in the above.

[oocube]

What is the fuzz about a bare clone? It is a clone of a repository similar as it would reside on a git server (=Github). There is the full history and all the branches but nothing is checked out. With that, there is no selected branch, no working directory and thus neither something to compile nor to base a version number on.

If during AUR build a bare clone is created, after that and before compilation some branch must be checked out. That is the moment when creating a version number becomes meaningful.

[LW-archlinux]

That is correct, everything needed for the version is available in the regular clone made from the bare clone at buildtime .

Just the remote_url points to the bare clone and the real remote url on the internet is only retrievable from the bare clone.

Replacing the local dir where the bare clone is with an envvar is also possible.

Choice which is preferred lies with oolite developers.

[oocube]

Thank you for the clarification.
So AUR builds clone the repository, then at some point perform a checkout. What exactly is getting checked out?
Is it a tag, a branch, or the default branch's head?