 |
 |
Hi, The package has moved to testing: - Fedora 28: https://bodhi.fedoraproject.org/updates/FEDORA-2018-9e2640da1e <https://bodhi.fedoraproject.org/updates/FEDORA-2018-9e2640da1e> - EPEL 7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3b68fe0e41 <https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3b68fe0e41> If folks could please take some time to review and test it, it'll help reduce the 2 week waiting period. Regardless, on the timescale of the next Xrootd release, libmacaroons should be present on at least a subset of the production platforms. Brian > On Jun 14, 2018, at 9:23 PM, Brian Bockelman <[log in to unmask]> wrote: > > Hi, > > I posted the proposed sources here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1591556 <https://bugzilla.redhat.com/show_bug.cgi?id=1591556> > > If there's anyone who can pickup the review and push it forward, it would be greatly appreciated. > > Brian > >> On Jun 14, 2018, at 10:15 AM, Andrew Hanushevsky <[log in to unmask] <mailto:[log in to unmask]>> wrote: >> >> Yes, I think that Michal is blessed as of now (as long as he doesn't make any mistakes :-). I suppose another reason to host it in the xroot github repo under, say, xrootd-macaroons. >> >> Andy >> >> On Thu, 14 Jun 2018, Fabrizio Furano wrote: >> >>> Are you a blessed EPEL packager ? >>> You need one to bless your package. Should not be difficult,as it's a >>> plain library. >>> >>> I think Michal may have this kind of power. >>> >>> About Debian I don't know personally. So far we got the key components >>> into it by courtesy (someone told me it was Mattias). I'd say that EPEL >>> comes first. >>> >>> f >>> >>> On 14.06.18 16:57, Brian Bockelman wrote: >>>> Hi, >>>> >>>> I can probably take care of this for EPEL, but I really have no background in Debian. >>>> >>>> Assuming we could get at least that far, could we get things into the main repo? >>>> >>>> Andy, your mention of "stock repos" was a bit ambiguous. Do you consider EPEL a stock repo for RHEL-like platforms? >>>> >>>> Brian >>>> >>>>> On Jun 14, 2018, at 7:15 AM, Andrew Hanushevsky <[log in to unmask] <mailto:[log in to unmask]>> wrote: >>>>> >>>>> Hi Fabrizio, >>>>> >>>>> I totally agree. We will not enbed libmacroons source into the xroot repo simply to avoid this kind of mess (for us and everyone else :-). So, I urge that you or whomever you lean on, repackge libmacaroons into an EPEL-style package that we can use without ever looking at the source. >>>>> >>>>> Andy >>>>> >>>>> >>>>> On Thu, 14 Jun 2018, Fabrizio Furano wrote: >>>>> >>>>>> Hi Andy, >>>>>> >>>>>> yes, development style is one thing, and so far the xrootd project >>>>>> has been very clear on that. >>>>>> >>>>>> In this case I had DPM in mind, and its WebDAV frontend >>>>>> already embedded the source of libmacaroons quite some time ago. >>>>>> Now we are talking about embedding the code of libmacaroons also in xrootd. >>>>>> >>>>>> The result would be to have potentially two different versions of >>>>>> the same code in the same DPM system, coming from two different >>>>>> frontends. >>>>>> >>>>>> It will work (I believe), yet the clean solution IMO is to properly >>>>>> package libmacaroons into EPEL+debian, so that noone needs to embed the code anymore. >>>>>> >>>>>> f >>>>>> >>>>>> >>>>>> On 06/14/2018 12:01 PM, Andrew Hanushevsky wrote: >>>>>>> Hi Fabrizio, >>>>>>> >>>>>>> I totally agree that having two source builds are a pain and should be avoided. I'm almost tempted to say should be prohibited. >>>>>>> In the xroot case, it should be possible to develop a plugin by installing the rpms you are dependent on and restricting >>>>>>> yourself to whatever public headers come with it. That's how it's done with all commonly used third party >>>>>>> packages. If can't develop that way then something is fundamentally wrong and should be corrected. Doing it that way, avoids the >>>>>>> exact problem you mention. So, I guess it comes down to how we enforce that kind of development style. Do you agree? >>>>>>> >>>>>>> Andy >>>>>>> >>>>>>> On Thu, 14 Jun 2018, Fabrizio Furano wrote: >>>>>>> >>>>>>>> Hi Andy, >>>>>>>> >>>>>>>> yes, that would be clean, and personally I would prefer to >>>>>>>> have libmacaroons in the stock repos. >>>>>>>> >>>>>>>> The annoyance I'd like to avoid is that so far DPM builds >>>>>>>> libmacaroons inside the source tree as an internal dep, >>>>>>>> exactly as you describe, for using it inside Apache. It's there >>>>>>>> since one year and a half... >>>>>>>> >>>>>>>> It would be quite annoying to have two versions of the same lib >>>>>>>> built inside the source tree of two different frontends: mod_lcgdm_dav >>>>>>>> and xrootd >>>>>>>> >>>>>>>> This is why I'd prefer to investigate if we can organize an "official" >>>>>>>> publishing of libmacaroons, at least to epel and debian. This thing >>>>>>>> has already been done in the past, and would represent to me the >>>>>>>> cleanest scenario possible, or at least it would give the possibility >>>>>>>> of having a clean situation. >>>>>>>> >>>>>>>> ... thoughts? >>>>>>>> >>>>>>>> Cheers >>>>>>>> Fabrizio >>>>>>>> >>>>>>>> >>>>>>>> On 14.06.18 09:55, Andrew Hanushevsky wrote: >>>>>>>>> In general, we do not add components to the main repo that depend on >>>>>>>>> third party libraries that are not available in a stock system. The >>>>>>>>> reasons for this should be obvious. The Macroon component is only one of >>>>>>>>> several components that people are developing with third party >>>>>>>>> dependencies. So we know we need to solve this problem. Our current >>>>>>>>> thinking is to setup additional projects in the main xroot repo to host >>>>>>>>> such developments and include them into our standard build pipeline. >>>>>>>>> Doing this should solve the dependency issue as well as making it >>>>>>>>> trivial to assign proper ownership so we aren't in the loop in terms of >>>>>>>>> updates and whatever. However, we would package them and sites could >>>>>>>>> install whatever they want via rpm. That way, those who wish to use a >>>>>>>>> feature know ahead of time that there will be additional libraries that >>>>>>>>> will be installed that we have no control over and may conflict with >>>>>>>>> whatever they already have installed. >>>>>>>>> >>>>>>>>> This seems the like the cleanest approach to this issue and avoids >>>>>>>>> leaving dead code in the main repo as these components come into and >>>>>>>>> fall out of favor. Michal and I have to work on this as we don't it in >>>>>>>>> place but should have a workable solution relatively soon. >>>>>>>>> >>>>>>>>> Andy >>>>>>>>> >>>>>>>>> On Wed, 13 Jun 2018, Fabrizio Furano wrote: >>>>>>>>> >>>>>>>>>> Hi Brian, >>>>>>>>>> >>>>>>>>>> true, macaroons are implemented by DPM and dcache. Having them also in >>>>>>>>>> xrootd >>>>>>>>>> would be great. >>>>>>>>>> >>>>>>>>>> About the distribution, my personal preference is to have these things >>>>>>>>>> handy to >>>>>>>>>> install and clean on the source tree, so I'd love to see macaroons and >>>>>>>>>> scitokens >>>>>>>>>> in the Xrd codebase, respecting all the strict project rules about >>>>>>>>>> makefiles (e.g. turning off the component) and deps. >>>>>>>>>> >>>>>>>>>> What did you do for libmacaroons? Since it's not distributed, we build >>>>>>>>>> it with DPM so far. >>>>>>>>>> Are you doing the same? >>>>>>>>>> Maybe we want to find a volunteer packager that submits it to >>>>>>>>>> epel/debian, etc. >>>>>>>>>> and only then refine the details of a build with Xrd ? >>>>>>>>>> >>>>>>>>>> Fabrizio >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 06/13/2018 04:08 PM, Brian Bockelman wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I have an initial (but functioning) support for Macaroons in Xrootd: >>>>>>>>>>> >>>>>>>>>>> https://github.com/bbockelm/xrootd-macaroons <https://github.com/bbockelm/xrootd-macaroons> >>>>>>>>>>> >>>>>>>>>>> Macaroons are a symmetric-key-based token format. It allows an >>>>>>>>>>> entity with access to the secret key generate a bearer token >>>>>>>>>>> embedding one more "caveats" (rules for usage, such as restrictions >>>>>>>>>>> on path, expiration time, or valid operations). The bearer >>>>>>>>>>> of the token can add additional caveats (reducing permission) but >>>>>>>>>>> doesn't have the ability to remove them. >>>>>>>>>>> >>>>>>>>>>> Anyone else with the secret key (such as the same host or another >>>>>>>>>>> host in the cluster) can then verify the token as apply the >>>>>>>>>>> authorization rules in the caveats. >>>>>>>>>>> >>>>>>>>>>> Why is this useful? A few cases: >>>>>>>>>>> >>>>>>>>>>> 1. Delegating fine-grained access: Rucio generates a token to access >>>>>>>>>>> a single file at a site (using its X509 client cert to >>>>>>>>>>> authenticate), then sends the token to an end-user. Hence, the >>>>>>>>>>> end-user doesn't need to authenticate with the site (no user >>>>>>>>>>> X509 necessary) in order to download files. The VO (ATLAS, via >>>>>>>>>>> Rucio) can manage the fine-grained rights they delegate to the >>>>>>>>>>> user -- even if the storage is run by the site. >>>>>>>>>>> >>>>>>>>>>> 2. Enabling third-party-copy: If client C wants server A to download >>>>>>>>>>> from server B, the client can contact server B for a >>>>>>>>>>> fine-grained access token and provide it to server A as part of the >>>>>>>>>>> HTTP COPY request. >>>>>>>>>>> - I suspect I'll get the first FTS3-based transfers working today. >>>>>>>>>>> >>>>>>>>>>> IIUC, Macaroons are implemented by dCache and DPM. I utilized the >>>>>>>>>>> same caveat formats and API for requesting new tokens, but >>>>>>>>>>> generally one would not expect tokens to be reusable across different >>>>>>>>>>> implementations or site installations. >>>>>>>>>>> >>>>>>>>>>> Currently, the token is generated via a XrdHttp plugin but should be >>>>>>>>>>> usable throughout the authorization framework; however, you >>>>>>>>>>> need an encrypted channel between client and server to use it safely. >>>>>>>>>>> >>>>>>>>>>> The obvious question is "how does this differ from SciTokens"? >>>>>>>>>>> - SciTokens are based on asymmetric (public key) cryptography whereas >>>>>>>>>>> Macaroons are symmetric key. This means anyone can verify >>>>>>>>>>> a SciToken but only the issuing entity can verify a Macaroon. >>>>>>>>>>> - In the SciTokens model, the VO issues the authorization, which may >>>>>>>>>>> be valid across many sites. The macaroon is specific to >>>>>>>>>>> the site and requires an interaction with the site to generate. >>>>>>>>>>> - Macaroons can be attenuated (made weaker) by the end-user. I can >>>>>>>>>>> take a powerful macaroon and add additional limitations >>>>>>>>>>> without contacting a third-party, then safely give the limited >>>>>>>>>>> macaroon to another person if I desire. SciTokens can only be >>>>>>>>>>> attenuated by contacting the VO to exchange the powerful one for a >>>>>>>>>>> new one (hence, the VO always generates the token). >>>>>>>>>>> >>>>>>>>>>> Just as one uses a mix of asymmetric and symmetric cryptography >>>>>>>>>>> throughout the course of the day, I see SciTokens and Macaroons >>>>>>>>>>> as complementary approaches, each enabling some distinct and some >>>>>>>>>>> common use cases. >>>>>>>>>>> >>>>>>>>>>> So - one natural question for me is whether this better lives inside >>>>>>>>>>> the xrootd repository or standalone. Unlike SciTokens, the >>>>>>>>>>> dependency stack for Macaroons is more manageable (a direct >>>>>>>>>>> dependency on libmacaroons - https://github.com/rescrv/libmacaroons >>>>>>>>>>> - and an indirect dependency on libbsd). This means upstreaming of >>>>>>>>>>> the macaroons code is more approachable than the SciTokens >>>>>>>>>>> code. Additionally, since the code includes both an issuer and a >>>>>>>>>>> verifier, Macaroons are more immediately usable - no >>>>>>>>>>> non-Xrootd services setup. >>>>>>>>>>> >>>>>>>>>>> Accordingly, I'm leaning to converting this into a module inside the >>>>>>>>>>> xrootd repository. >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> >>>>>>>>>>> Brian >>>>>>>>>>> >>>>>>>>>>> -------------------------------------------------------------------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Use REPLY-ALL to reply to list >>>>>>>>>>> >>>>>>>>>>> To unsubscribe from the XROOTD-DEV list, click the following link: >>>>>>>>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ######################################################################## >>>>>>>>>> Use REPLY-ALL to reply to list >>>>>>>>>> >>>>>>>>>> To unsubscribe from the XROOTD-DEV list, click the following link: >>>>>>>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 <https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1> >>>>>>>>>> >>>>>>>>> >>>>>>>>> ######################################################################## >>>>>>>>> Use REPLY-ALL to reply to list >>>>>>>>> >>>>>>>>> To unsubscribe from the XROOTD-DEV list, click the following link: >>>>>>>>> https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 <https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >>> >>> >>> > > > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-DEV list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 <https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1