Improve integration of the http server introduced by the http-registry feature.
Now the same HTTP server is used for serving downloads, the index, and
the API.
This makes it easier to write tests that deal with authentication and
http registries.
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
Remove `build_script::build_script_scan_eacces` test case because cargo
ignores it and returns its path during a `cargo build`. The caller still
has a chance to hit the IO error if they does access it.
If `cargo package` is run on a package that specifies a git dependency
without a version, cargo will error. This should help with clarifying
that git dependencies will be stripped when packaging, and that the
dependency has to be fetched from a registry.
This commit fixes an issue where packages which specify `resolver = '2'`
cannot be packaged if they also have a `package.metadata` table. The
issue is that the `toml` serialization implementation serializes fields
in order which requires that tables be emitted last.
Currently, when reading a file from disk, we include several pieces of
data from the on-disk file, including the user and group names and IDs,
the device major and minor, the mode, and the timestamp. This means
that our archives differ between systems, sometimes in unhelpful ways.
In addition, most users probably did not intend to share information
about their user and group settings, operating system and disk type, and
umask. While these aren't huge privacy leaks, cargo doesn't use them
when extracting archives, so there's no value to including them.
Since using consistent data means that our archives are reproducible and
don't leak user data, both of which are desirable features, let's
canonicalize the header to strip out identifying information.
Omit the inclusion of the timestamp for generated files and tell the tar
crate to copy deterministic data. That will omit all of the data we
don't care about and also canonicalize the mode properly.
Our tests don't check the specifics of certain fields because they
differ between the generated files and the files that are archived from
the disk format. They are still canonicalized correctly for each type,
however.
Currently, when reading a file from disk, we include several pieces of
data from the on-disk file, including the user and group names and IDs,
the device major and minor, the mode, and the timestamp. This means
that our archives differ between systems, sometimes in unhelpful ways.
In addition, most users probably did not intend to share information
about their user and group settings, operating system and disk type, and
umask. While these aren't huge privacy leaks, cargo doesn't use them
when extracting archives, so there's no value to including them.
Since using consistent data means that our archives are reproducible and
don't leak user data, both of which are desirable features, let's
canonicalize the header to strip out identifying information.
We set the user and group information to 0 and root, since that's the
only user that's typically consistent among Unix systems. Setting
these values doesn't create a security risk since tar can't change the
ownership of files when it's running as a normal unprivileged user.
Similarly, we set the device major and minor to 0. There is no useful
value here that's portable across systems, and it does not affect
extraction in any way.
We also set the timestamp to the same one that we use for generated
files. This is probably the biggest loss of relevant data, but
considering that cargo doesn't otherwise use it and honoring it makes
the archives unreproducible, we canonicalize it as well.
Finally, we canonicalize the mode of an item we're storing by looking at
the executable bit and using mode 755 if it's set and mode 644 if it's
not. We already use 644 as the default for generated files, and this is
the same algorithm that Git uses to determine whether a file should be
considered executable. The tests don't test this case because there's
no portable way to create executable files on Windows.
This commit is targeted at further improving the error messages
generated from git errors. For authentication errors the actual URL
fetched is now printed out as well if it's different from the original
URL. This should help handle `insteadOf` logic where SSH urls are used
instead of HTTPS urls and users can know to track that down.
Otherwise the logic about recommending `net.git-fetch-with-cli` was
tweaked a bit and moved to the same location as the rest of our error
reporting.
Note that a change piggy-backed here as well is that `Caused by:` errors
are now automatically all tabbed over a bit instead of only having the
first line tabbed over. This required a good number of tests to be
updated, but it's just an updated in renderings.
Hint upgrading for future edition keys
A more specific error message for potentially-future edition values.
This error is likely to be seen by people who are not regular Rust users and are just trying to build someone's crate. It may be helpful to stronger hint at upgrading Cargo, rather than display a more general message about an unknown value.
I know Cargo plans to fix it better with explicit MSRV eventually, but that's not ready yet, so it's better to land something sooner.
include dotfiles in packages
This PR solves #7183
It changes the behavior of `cargo package` to also include dotfiles by default.
It should be discussed if this is intended or if the implementation should be changed to only include dotfiles which are specified in the `include` section.
From the [existing comment](40885dfab4/src/cargo/sources/path.rs (L358)) it is a little bit unclear to me, but I supposed it was intended only to exclude directories starting with a dot?
fixes#7003
Explicitly state what the suggested flag `--allow-dirty`
actually does when packaging/publishing the crate. Primarily,
that the uncommited changes are included within the resulting
package.
