You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@slider.apache.org by Sumit Mohanty <sm...@hortonworks.com> on 2014/07/09 22:57:04 UTC
What is the best way to share pre-created application packages?
Any idea on how we can share pre-created application packages? Is there an
Apache recommendation around it?
-Sumit
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: What is the best way to share pre-created application packages?
Posted by Billie Rinaldi <bi...@gmail.com>.
I think the maven artifacts are signed (at least when deploying them
through an ASF release process
http://www.apache.org/dev/publishing-maven-artifacts.html). But the
checksums are still an issue.
On Thu, Jul 10, 2014 at 3:28 AM, Steve Loughran <st...@hortonworks.com>
wrote:
> On 9 July 2014 21:57, Sumit Mohanty <sm...@hortonworks.com> wrote:
>
> > Any idea on how we can share pre-created application packages? Is there
> an
> > Apache recommendation around it?
> >
> >
> the defacto ASF way would be to publish them to the maven central
> repository and let maven/ivy/... retrieve it. That handles replication and
> basic checksumming, but
> -would lead to massive ~/.m2/repository bloat
> -doesn't do real security, given the artifacts aren't signed and the MD5
> checksum is fetched from the mirror server publishing the binaries. Serving
> malicious artifacts based on requester ID is an obvious attack.
>
>
> I think long term we do need a story here, but short term: just publish
> them alongside slider itself.
>
> Longer term? I'd like some kind of repository URLs + list of public keys
> you trust, slider could list available artifacts, download them to hdfs.
> This is of course what YUM and debian repositories do.
>
> If we do something like that, then we have to do it securely, which is why
> I don't think we should rush into it. You have to think about key
> propagation/revocation and the like. And before anyone says "just use
> HTTPS", know that this would stop you publishing from Amazon S3, Azure, etc
> unless you want to give anyone with an S3 or AVS blobstore full rights to
> publish what appear to be trusted artifacts:
>
> http://stackoverflow.com/questions/11201316/how-to-configure-ssl-for-amazon-s3-bucket
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
Re: What is the best way to share pre-created application packages?
Posted by Sumit Mohanty <sm...@hortonworks.com>.
Thanks Steve. Let me capture this in a JIRA and track it for a later
release.
On Thu, Jul 10, 2014 at 3:28 AM, Steve Loughran <st...@hortonworks.com>
wrote:
> On 9 July 2014 21:57, Sumit Mohanty <sm...@hortonworks.com> wrote:
>
> > Any idea on how we can share pre-created application packages? Is there
> an
> > Apache recommendation around it?
> >
> >
> the defacto ASF way would be to publish them to the maven central
> repository and let maven/ivy/... retrieve it. That handles replication and
> basic checksumming, but
> -would lead to massive ~/.m2/repository bloat
> -doesn't do real security, given the artifacts aren't signed and the MD5
> checksum is fetched from the mirror server publishing the binaries. Serving
> malicious artifacts based on requester ID is an obvious attack.
>
>
> I think long term we do need a story here, but short term: just publish
> them alongside slider itself.
>
> Longer term? I'd like some kind of repository URLs + list of public keys
> you trust, slider could list available artifacts, download them to hdfs.
> This is of course what YUM and debian repositories do.
>
> If we do something like that, then we have to do it securely, which is why
> I don't think we should rush into it. You have to think about key
> propagation/revocation and the like. And before anyone says "just use
> HTTPS", know that this would stop you publishing from Amazon S3, Azure, etc
> unless you want to give anyone with an S3 or AVS blobstore full rights to
> publish what appear to be trusted artifacts:
>
> http://stackoverflow.com/questions/11201316/how-to-configure-ssl-for-amazon-s3-bucket
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.
Re: What is the best way to share pre-created application packages?
Posted by Steve Loughran <st...@hortonworks.com>.
On 9 July 2014 21:57, Sumit Mohanty <sm...@hortonworks.com> wrote:
> Any idea on how we can share pre-created application packages? Is there an
> Apache recommendation around it?
>
>
the defacto ASF way would be to publish them to the maven central
repository and let maven/ivy/... retrieve it. That handles replication and
basic checksumming, but
-would lead to massive ~/.m2/repository bloat
-doesn't do real security, given the artifacts aren't signed and the MD5
checksum is fetched from the mirror server publishing the binaries. Serving
malicious artifacts based on requester ID is an obvious attack.
I think long term we do need a story here, but short term: just publish
them alongside slider itself.
Longer term? I'd like some kind of repository URLs + list of public keys
you trust, slider could list available artifacts, download them to hdfs.
This is of course what YUM and debian repositories do.
If we do something like that, then we have to do it securely, which is why
I don't think we should rush into it. You have to think about key
propagation/revocation and the like. And before anyone says "just use
HTTPS", know that this would stop you publishing from Amazon S3, Azure, etc
unless you want to give anyone with an S3 or AVS blobstore full rights to
publish what appear to be trusted artifacts:
http://stackoverflow.com/questions/11201316/how-to-configure-ssl-for-amazon-s3-bucket
--
CONFIDENTIALITY NOTICE
NOTICE: This message is intended for the use of the individual or entity to
which it is addressed and may contain information that is confidential,
privileged and exempt from disclosure under applicable law. If the reader
of this message is not the intended recipient, you are hereby notified that
any printing, copying, dissemination, distribution, disclosure or
forwarding of this communication is strictly prohibited. If you have
received this communication in error, please contact the sender immediately
and delete it from your system. Thank You.