[Git][reproducible-builds/reproducible-website][master] env-var: avoid here links

Mon Aug 5 08:38:26 UTC 2024


Mattia Rizzolo pushed to branch master at Reproducible Builds / reproducible-website


Commits:
3cbd4902 by hulkoba at 2024-08-05T08:36:47+00:00
env-var: avoid here links

- - - - -


1 changed file:

- _docs/environment_variations.md


Changes:

=====================================
_docs/environment_variations.md
=====================================
@@ -22,7 +22,7 @@ Architecture Information
 
 Architecture information refers to crucial details concerning the Linux kernel version and hardware architecture name, which are obtained through the use of the `uname` utility. When builds are conducted on different build systems, invoking the `uname` utility may yield diverse hardware architecture and kernel versions, which are then compiled into the resulting artifacts. This variation in architecture information leads to unreproducible builds, as the artifacts produced on different build systems will differ due to the discrepancies in the kernel version and hardware architecture used during the build process.
 
-For instance, during the build process of the `systemd` package, a call is made to the `uname` utility for debugging purposes. This call retrieves the hardware architecture of the build system. In one scenario, the build was performed on a system with the `i686` architecture, while in another, it was executed on a system with the `x86_64` architecture. Consequently, this difference in architectural information is reflected in the resulting artifacts, causing the builds to become unreproducible due to the varying hardware architectures used during the build process as seen [here](https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_arch_issue.html)
+For instance, during the build process of the `systemd` package, a call is made to the `uname` utility for debugging purposes. This call retrieves the hardware architecture of the build system. In one scenario, the build was performed on a system with the `i686` architecture, while in another, it was executed on a system with the `x86_64` architecture. Consequently, this difference in architectural information is reflected in the resulting artifacts, causing the builds to become unreproducible due to the varying hardware architectures used during the build process. For more details, you can refer to the [issue](https://tests.reproducible-builds.org/debian/issues/unstable/captures_build_arch_issue.html).
 
 Build ID
 --------
@@ -50,7 +50,7 @@ However, it is essential to recognize that relying solely on timestamps provides
 
 An example of a timestamp variation would be the [C pre-defined macros](https://tests.reproducible-builds.org/debian/issues/unstable/timestamps_from_cpp_macros_issue.html) such as `_Date_` and `_Time_` are utilized to output the current time. It is important to note that when these macros are invoked by distinct build systems, different timestamps are incorporated into the compiled code, resulting in variations in the generated build artifacts.
 
-**Workaround:** The SOURCE_DATE_EPOCH environment variable has been introduced as a solution to address the challenges related to build timestamps and facilitate reproducible builds. The value assigned to the SOURCE_DATE_EPOCH variable represents the timestamp of the most recent modification made to the source code for a specific release. This timestamp is usually derived from the source changelog file, ensuring consistent and accurate build time determination across various build systems
+**Workaround:** The SOURCE_DATE_EPOCH environment variable has been introduced as a solution to address the challenges related to build timestamps and facilitate reproducible builds. The value assigned to the SOURCE_DATE_EPOCH variable represents the timestamp of the most recent modification made to the source code for a specific release. This timestamp is usually derived from the source changelog file, ensuring consistent and accurate build time determination across various build systems.
 
 For comprehensive details on the usage and implementation of the SOURCE_DATE_EPOCH variable, we refer to the provided [specification]({{ "/docs/source-date-epoch/" | relative_url }}).
 
@@ -68,14 +68,14 @@ Filesystem Ordering
 
 The order in which files are created and displayed within the filesystem can have a significant impact on the reproducibility of artifacts. When distinct builds are executed, variations in the file order can occur, which, in turn, leads to a different ordering of segments inside the generated artifacts.
 
-For instance, in the case of Ruby 2.3, the presence of `mkmf.rb` is notable. This script is responsible for automatically generating Makefiles for multiple Ruby applications. However, a critical issue arises from the fact that the generated Makefiles do not sort the list of object files. Consequently, when distinct builds are performed, the resulting build logs capture the compilation process in an unordered manner. This lack of order in the compilation can directly impact the resulting artifacts, rendering them unreproducible. More information on this issue can be found [here](https://tests.reproducible-builds.org/debian/issues/unstable/ruby_mkmf_makefile_unsorted_objects_issue.html).
+For instance, in the case of Ruby 2.3, the presence of `mkmf.rb` is notable. This script is responsible for automatically generating Makefiles for multiple Ruby applications. However, a critical [issue](https://tests.reproducible-builds.org/debian/issues/unstable/ruby_mkmf_makefile_unsorted_objects_issue.html) arises from the fact that the generated Makefiles do not sort the list of object files. Consequently, when distinct builds are performed, the resulting build logs capture the compilation process in an unordered manner. This lack of order in the compilation can directly impact the resulting artifacts, rendering them unreproducible.
 
 File Permission
 ---------------
 
 During a software build, new files are created, inheriting predefined file permissions from the containing folder. However, the default file permissions assigned to these new files can vary across different build systems. This discrepancy in default permissions can introduce inconsistencies when attempting to reproduce the build process, ultimately affecting the reliability and trustworthiness of the resulting software.
 
-For instance, during the execution of distinct builds, the usage of the `umask` utility has been observed to introduce unreproducibility. When the umask value varies across different build systems, the default permissions assigned to files during the build process can differ as seen [here](https://tests.reproducible-builds.org/debian/issues/unstable/different_due_to_umask_issue.html). For example, one build system may have a more permissive umask value, resulting in wider permissions for files, while another build system may have a more restrictive umask value. These disparities in file permissions become embedded in the compiled artifacts, making it challenging to reproduce identical builds.
+For instance, during the execution of distinct builds, the usage of the `umask` utility has been observed to introduce unreproducibility. When the umask value varies across different build systems, the default permissions assigned to files during the build process can differ. This discrepancy is documented in [this issue](https://tests.reproducible-builds.org/debian/issues/unstable/different_due_to_umask_issue.html). For example, one build system may have a more permissive umask value, resulting in wider permissions for files, while another build system may have a more restrictive umask value. These disparities in file permissions become embedded in the compiled artifacts, making it challenging to reproduce identical builds.
 
 Locale
 ------
@@ -104,7 +104,8 @@ Randomness introduces an element of unpredictability to data stored in data stru
 
 One specific manifestation of this randomness can be observed in the context of software packaging in Debian. Here, `control.tar.gz` is a compressed file that contains metadata about the package such as the list of files in the package and their respective checksums (md5sums). This is crucial for verifying the integrity of the files in the package.
 
-When creating a Debian package, non-determinism may arise due to the varying order of files listed in md5sums between different builds, found in the `control.tar.gz` file. This usually happens when the package does not use `dh_md5sums`, and the `find` command is used to list the files, which does not guarantee a consistent order. More information on this issue can be found [here](https://tests.reproducible-builds.org/debian/issues/unstable/random_order_in_md5sums_issue.html).
+When creating a Debian package, non-determinism may arise due to the varying order of files listed in md5sums between different builds, found in the `control.tar.gz` file. This usually happens when the package does not use `dh_md5sums`, and the `find` command is used to list the files, which does not guarantee a consistent order.
+More information can be found in [this issue](https://tests.reproducible-builds.org/debian/issues/unstable/random_order_in_md5sums_issue.html).
 
 For comprehensive details on the randomness, we refer to the provided [documentation]({{ "/docs/randomness/" | relative_url }}).
 
@@ -115,14 +116,14 @@ Reference to Memory Address
 
 In the context of reproducible builds, a reference to a memory address pertains to numerical representations of particular memory locations within build environments. These memory addresses are utilized by data structures in various programming languages like C and Python to access specific locations in memory. The issue arises when, during the execution of separate builds, the same object is allocated different memory addresses, leading to varying content stored in the resulting artifacts. This disparity in memory allocation causes the build process to become unreproducible, as the output artifacts are no longer identical.
 
-For instance, the `ldaptor` package relies on a python module called [weakref](https://docs.python.org/3/library/weakref.html). Within this `weakref` python module, the "_repr_" [function](https://docs.python.org/3/library/functions.html#repr) is utilized. This particular function is responsible for generating the memory address of the instance passed to it. However, the instances provided to this function yield different memory addresses, which ultimately become part of the compiled artifacts. As a consequence, this discrepancy in memory addresses leads to unreproducible builds as seen [here](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827416).
+For instance, the `ldaptor` package relies on a python module called [weakref](https://docs.python.org/3/library/weakref.html). Within this `weakref` python module, the "_repr_" [function](https://docs.python.org/3/library/functions.html#repr) is utilized. This particular function is responsible for generating the memory address of the instance passed to it. However, the instances provided to this function yield different memory addresses, which ultimately become part of the compiled artifacts. As a consequence, this discrepancy in memory addresses leads to unreproducible builds, as documented in [this bug report](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827416).
 
 Snippet Encoding
 ----------------
 
 Snippet Encoding is the process of encoding strings or specific segments of a file using random numbers. These random numbers, functioning as security keys, are utilized to encode data and prevent unauthorized usage. Within the build execution, these randomized digits are incorporated into the resulting artifacts. Since distinct build systems generate different sets of randomized digits, the resulting build artifacts exhibit varying content.
 
-For instance, during the execution of distinct builds, the usage of the `srandom` utility has been observed to introduce unreproducibility. This utility is employed to provide a seed value to the randomization function, ensuring randomness in the generated output. However, it was found that the seed value stored in the resulting build artifact differed for each build, leading to unreproducible outcomes as seen [here](https://tests.reproducible-builds.org/debian/issues/unstable/markdown_random_email_address_html_entities_issue.html).
+For instance, during the execution of distinct builds, the usage of the `srandom` utility has been observed to introduce unreproducibility. This utility is employed to provide a seed value to the randomization function, ensuring randomness in the generated output. However, it was found that the seed value stored in the resulting build artifact differed for each build, leading to unreproducible outcomes as seen [in this issue](https://tests.reproducible-builds.org/debian/issues/unstable/markdown_random_email_address_html_entities_issue.html).
 
 System DNS Name
 ---------------
@@ -134,11 +135,11 @@ Uninitialized Memory
 
 In the context of reproducible builds, uninitialized memory refers to the unutilized memory assigned to resources like data structures or file systems. For example, data structures in various programming languages may receive larger memory allocations than necessary, and to optimize performance, this extra memory is filled with randomized padding. The issue arises when resources utilizing this uninitialized memory are stored in files, which could be linked into the resulting artifact during the execution of different builds. As a consequence, this variation in the inclusion of uninitialized memory in the files leads to unreproducible builds, as the resulting artifacts differ due to the random padding introduced during the build process.
 
-For instance, during the build process of the `ipadic` package, a `.dat` file is created, which includes uninitialized memory. To address this, randomized padding is applied to fill the uninitialized memory. However, when different build systems execute builds for the `ipadic` package, the resulting artifacts contain the `.dat` files with varying randomized padding. As a consequence, this discrepancy in the content of the `.dat` files causes the `ipadic` package to become unreproducible on Debian and openSUSE platforms as seen [here](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881231).
+For instance, during the build process of the `ipadic` package, a `.dat` file is created, which includes uninitialized memory. To address this, randomized padding is applied to fill the uninitialized memory. However, when different build systems execute builds for the `ipadic` package, the resulting artifacts contain the `.dat` files with varying randomized padding. As a consequence, this discrepancy in the content of the `.dat` files causes the `ipadic` package to become unreproducible on Debian and openSUSE platforms as seen [in this bug report](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=881231).
 
 User Information
 ----------------
 
 User information refers to data that discloses a user's identity, including their username, which has the potential to be included in the build logs. If this user information becomes captured in the resulting artifacts, it can lead to divergent build outputs, causing the builds to become unreproducible.
 
-For instance, during the build process of the `gnustep-base` package, the string `generated by $USER` is executed, where `$USER` represents the name of the system's user who is executing the build. The issue arises when builds are performed on different build systems, as the `$USER` variable outputs distinct usernames for each system. As a result, this variation in the captured user information causes the builds to become unreproducible, as the resulting artifacts will contain different usernames due to the diverse build environments as seen [here](https://tests.reproducible-builds.org/debian/issues/unstable/user_in_documentation_generated_by_gsdoc_issue.html).
+For instance, during the build process of the `gnustep-base` package, the string `generated by $USER` is executed, where `$USER` represents the name of the system's user who is executing the build. The issue arises when builds are performed on different build systems, as the `$USER` variable outputs distinct usernames for each system. As a result, this variation in the captured user information causes the builds to become unreproducible, as the resulting artifacts will contain different usernames due to the diverse build environments as seen [in this issue](https://tests.reproducible-builds.org/debian/issues/unstable/user_in_documentation_generated_by_gsdoc_issue.html).



View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/3cbd4902b1dfa4fc55cd0e1fdd5418c257ff60c9

-- 
View it on GitLab: https://salsa.debian.org/reproducible-builds/reproducible-website/-/commit/3cbd4902b1dfa4fc55cd0e1fdd5418c257ff60c9
You're receiving this email because of your account on salsa.debian.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.reproducible-builds.org/pipermail/rb-commits/attachments/20240805/29f6e640/attachment.htm>
