<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Sean,</p>
<p>You can use any of the existing cloud-storage oriented
configuration option, so for example for AWS, you could just set
the AWS_PROFILE (being one listed in
<a class="moz-txt-link-freetext" href="https://gdal.org/user/virtual_file_systems.html#vsis3-aws-s3-files">https://gdal.org/user/virtual_file_systems.html#vsis3-aws-s3-files</a>)
that corresponds to a path. The main use case was for code that
constantly switches between buckets of the same provider that have
different credentials, and where having to swap between the right
configuration options constantly is a pain, but indeed it might
also be convenient for command line usage where you have to deal
with the same recurring buckets.<br>
</p>
<div class="moz-cite-prefix">Le 24/03/2022 à 16:12, Sean Gillies a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAOodmJqe7PXjC7tOGFmVCoRwhSE9gAQ+bdeu492MP+gD5DF5OQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Even,</div>
<div><br>
</div>
<div>At the very least, the new file duplicates storage of
credentials that may already be stored in cloud-specific
credentials files, and creates a new way for users to expose
their secrets. Also, cloud providers and organizations have
moved or are moving to focusing on short-lived credentials,
SSO, etc. How useful is a cross-cloud credentials file if it
supports only static credentials? Why not support named
profiles already defined in cloud-specific files? Python and
C++ programmers haven't needed this framework because they can
maintain their own maps of credentials or roles to resources,
so I guess this feature is mainly for command line users? Do
command line users do this kind of thing enough to warrant a
new framework?<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Mar 24, 2022 at 8:45
AM Even Rouault <<a
href="mailto:even.rouault@spatialys.com"
moz-do-not-send="true" class="moz-txt-link-freetext">even.rouault@spatialys.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>Sean,</p>
<p>I saw them as business-as-usual enhancements not
impacting the software in fundamental ways. I'm not sure
what I would put in a RFC that is not in their commit
message. Maybe I don't understand what your concern is.</p>
<p>Even<br>
</p>
<div>Le 24/03/2022 à 15:28, Sean Gillies a écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Hi all,</div>
<div><br>
</div>
<div>The intent and scope of the features developed in
<a href="https://github.com/OSGeo/gdal/pull/5463"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/OSGeo/gdal/pull/5463</a>
and <a
href="https://github.com/OSGeo/gdal/pull/5390"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://github.com/OSGeo/gdal/pull/5390</a>
seem rather big and unclear to me. This seems to me
to warrant an RFC. Yes? No?<br>
</div>
<div><br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br>
-- <br>
<div dir="ltr" class="gmail_signature">Sean Gillies</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>