bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#74413: [PATCH] Allow to store and read repository information of VCS


From: Stefan Kangas
Subject: bug#74413: [PATCH] Allow to store and read repository information of VCS builds
Date: Mon, 18 Nov 2024 18:48:31 -0500

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Björn Bidar <bjorn.bidar@thaodan.de>
>> Cc: Po Lu <luangruo@yahoo.com>,  74413@debbugs.gnu.org
>> Date: Mon, 18 Nov 2024 16:21:28 +0200
>>
>> > Doesn't that go against the tendency to have _less_ detailed/private
>> > information in the build?  We've lately removed some relatively useful
>> > infos from what we report in commands that use the build information.
>>
>> The information added is only the branch and the repository similarly as
>> used by the Android builds. There's no private information there unless
>> the exact change reference Emacs was built on is private.
>
> The branch name could be private.
>
> Stefan, WDYT about this feature suggestion?

The privacy risk here is that if a user is building their own private
branch, announcing the sha or branch name to the world can be used to
uniquely identify that user.  It would be a serious privacy issue if we,
for example, included that information in User-Agent headers sent by EWW
or other kinds of network traffic.  AFAIK, we don't do that.

IIUC, we use this information only when submitting bug reports.  I think
this is harmless, if we assume privacy threat models where it can also
be considered safe to report bugs.  The few users that have more strict
privacy requirements, and are eager to report bugs, will just have to
think about this detail themselves; it's a rather specialized use case.

IOW, I don't think I see a reason to object on these grounds.

Björn Bidar <bjorn.bidar@thaodan.de> writes:

> The additions to the make file are so that if the worker contains git
> the file can be generated so that the related functions will still work
> after the built or to generate them prior the built. The latter probably
> makes less sense except to maybe avoid having autotools in the built
> dependency chain.
>
> If the Make recipe isn't used to generate the version file it can be
> generated by the CI, e.g. in my case I take the information from the
> open build source service. For others such as Fedora the sources can be
> retrieved in a similar manner.
>
> The file can be added before the built starts and package  so that the pdump
> will contain the repository information and the VCS function will also
> work afterwards.

I don't fully understand how you can have a situation where you can get
this information in the Makefile, but you can't also get it when dumping
using `emacs-repository-get-version` and `emacs-repository-get-branch`
(lisp/loadup.el:474).  Could you please elaborate on this?

Do you mean that you have one containerized process with Git that clones
emacs.git into a directory, and then an entirely separate containerized
process, without Git, builds Emacs from that very same directory?  Or
something along those lines?

In this very particular scenario, isn't it enough to add this
additional step to your CI pipeline:

    ./src/emacs -Q --batch --eval '(princ (format "%s:%s" \
    emacs-repository-version emacs-repository-branch))' > version.info

?

In other words, is it really necessary for us to support this use case
in our Makefile?  Do we expect that building Emacs in such CI pipelines
using non-released development version of Emacs will be very common?

BTW, what is the name of that CI system that you're using here?  For
what purpose are you building Emacs: to test Elisp packages, to test
Emacs, or something else?  Finally, why are you not using officially
tagged versions, either from us or from some distro, in this context?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]