If both GOBIN and GOPATH aren't set in the system environment then the
makefile will attempt to install to /bin. go env uses a sensible default
of $HOME/go if GOPATH isn't set.
Signed-off-by: James Hewitt <james.hewitt@uk.ibm.com>
The Skopeo branch to test against is now driven by
SKOPEO_CI_TAG in .cirrus.yml, these are not used by anything.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Operations that involve encryption/decryption are already restricted
e.g. not to use TryReusingBlob; but operations that don't themselves
involve encryption could still find encrypted blobs in the blob info cache,
and potentially use them in other contexts.
To avoid that, use a somewhat big hammer of just not calling
RecordDigestUncompressedPair on that. Note that this does not
help if the blob info cache has already added such entries before this
change; it only makes a difference for the future.
We continue to call RecordKnownLocation with encrypted data; simple
copies of encrypted images from one registry to another (which don't
encrypt/decrypt as part of the copy) can benefit from e.g. cross-repo
blob reuse just fine.
It seems likely that a more precise logic which records more data
and allows more blob reuse could be built, but it's not trivially
obvious to me that it would be safe, so this change only does the
conservative thing to avoid known breakage.
There is another RecordDigestUncompressedPair call in c/image/storage;
that one is safe, because it only works on a pair of unencrypted
digests (for a compressed layer, PutBlobWithOptions receives an empty
digest value, and a necessarily decrypted data stream; using that,
it computes is own digests of the decrypted possibly-compressed
and unencrypted uncommpressed data streams).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
AFAICS encryption doesn't _actually_ need diffIDs, at least I
can't see any encryption-related use of the computed value; the boolean
seems to only be set to avoid reuse (which risks unwanted reuse of
plaintext data, or revealing relationships between ciphertext/plaintext
to network observers).
So, use two extra variables to be clear about the logic of the code.
(Also reorder one condition to check a local variable first before calling
methods, a microoptimizaion.)
Should not change outcome of the operation (but the time and CPU usage
no longer spent to unnecessarily compute DiffID values might be noticeable).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The two latest commits in c/ocicrypt get rid of OAEPDefaultHash envvar
and default to sha256.
They are waiting for confirmation on their rust side before cutting a
release. So, hoping to get this in assuming dependabot could take a
while.
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
If srcInfo.Size == -1, the progress bar is not showing the
refill value anyway (customPartialBlobDecorFunc is only
used if size is known), so don't bother calling this function
with nonsense data, if anything, at least to emphasize that this
condition is, in principle, possible.
Should not affect behavior, hopefully.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This correctly handles both the "size known" and the "size unknown" cases,
and because we now record the originally-configured progress bar size
in the progressBar struct, the caller doesn't need to track it.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This will allow us to add more state and methods to the bar
object, without copy&pasting.
For now, this just wraps one pointer in another, and should
not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
In particular, if the source is compressed, track the full size
of the original compressed blob in the progress bar, even if the decompressed
version has a different size (e.g. because the encryption adds a header or a MAC).
This original size is easy to determine and eaiser to explain to users; so let's do
the simple thing.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Already draw the progress bar before opening the source's layer
or config blob, so that the users can have a visual indication
of something related to that blob happening if it takes too long.
(For the .ConfigBlob() call, this might not make a difference,
because in _some_ cases we trigger reading the config via
.OCIConfig in checkImageDestinationForCurrentRuntime(), and the
config blob is cached, but it might make a difference in the other
cases, and it doesn't hurt in this one.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
The same srcInfo.size was passed to createProgressBar, so this
does nothing at best if size is known; if it is unknown,
it seems to effectively also be a no-op with a recent version of mpb
(it sets the total value to 0, the current progress at the time,
but it doesn't enable auto-complete, so it doesn't make a difference).
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... to cleanly differentiate the code related to chan<- types.ProgressProperties
from the code related to progress bars.
Only moves unchanged code, should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Second part: Move blobChunkAccessorProxy to the newly established
progress_bars.go.
Only moves unchanged code, should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Let's try to make copy.go shorter, and consolidate progress bar code to
new copy/progress_bars.go.
First, move the code from copy.go.
Only moves unchanged code, should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Per https://github.com/containers/image/issues/1010 , it seems
the header is not populated by AWS ECR.
We were actually computing the digest from the manifest bytes
already, so this is both more robust and simpler.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Just a micro-optimization: avoid maintaining state for
a read/write buffer, and the allocation inherent in a
string -> []byte conversion.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Four leading spaces are interpreted by go-md2man as a code block.
Add a new line to start a new paragraph, so that go-md2man recognizes
the list syntax.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Clarify that a `[[registry.mirror]]` is associated only with the
previous `[[registry]]`.
Fixes: #1523
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
Miloslav Trmač