Support `git describe` in versionformat about obs-service-tar_scm HOT 15 OPEN

After looking around this seems like what is being asked for in #55 as well?

from obs-service-tar_scm.

Yes, in principal I'm in favour of something more flexible, as long as it doesn't introduce security holes.

from obs-service-tar_scm.

One approach might be to support something like this:

<param name="versionformat">%gd</param>
<param name="git-describe">--match='v[0-9]*'</param>
<param name="git-describe-sed">s/^v//; s/-g[0-9a-f]\{7\}$//; s/-/+/</param>

So that if the closest tag was v1.2.3 and there have been 4 commits since that tag, then the version would be 1.2.3+4.

Although this has the limitation of only allowing a single string to be extracted from git describe.

from obs-service-tar_scm.

@aspiers There a rpm version issue with +4, as this leads to the situation, where v1.2.3.1 would be seen below v1.2.3+1. Better would be using '~' instead of '+', as this is special cased.

from obs-service-tar_scm.

@frispete Right - thanks for the heads up on that :)

from obs-service-tar_scm.

Actually, I think a better way of solving this would be to allow execution of an arbitrary command (which could be a script within the package) which would be responsible for determining the version, e.g.

<param name="version-command">extract-git-version.sh</param>

or

<param name="version-command">git describe --match='v[0-9]*' | sed 's/^v//; s/-g[0-9a-f]\{7\}$//; s/-/+/'</param>

However this would allow arbitrary command execution within source service runs, which could be a gaping security hole. @adrianschroeter Are server-side source service runs done in a security-isolated sandbox? i.e. is this a problem we already have to deal with in other source services, or would it be introducing a big new security issue?

from obs-service-tar_scm.

On Dienstag, 21. Juni 2016, 04:52:30 CEST wrote Adam Spiers:

Actually, I think a better way of solving this would be to allow execution of an arbitrary command (which could be a script within the package) which would be responsible for determining the version, e.g.

this is IMHO not a good idea, it would make it quite dangerous to use the
service then.

It should be always safe to checkout and build a package source
without the need of checking the sources. Otherwise it is a security
issue.

<param name="version-command">extract-git-version.sh</param>

or

<param name="version-command">git describe --match='v[0-9]*' | sed 's/^v//; s/-g[0-9a-f]\{7\}$//; s/-/+/'</param>

However this would allow arbitrary command execution within source service runs, which could be a gaping security hole. @adrianschroeter Are server-side source service runs done in a security-isolated sandbox? i.e. is this a problem we already have to deal with in other source services, or would it be introducing a big new security issue?

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#60 (comment)

Adrian Schroeter
email: [email protected]

SUSE Linux GmbH, GF: Felix Imend�rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N�rnberg)

Maxfeldstra�e 5
90409 N�rnberg
Germany

from obs-service-tar_scm.

OK, forget that idea then ;-)

from obs-service-tar_scm.

I wrote:

Although this has the limitation of only allowing a single string to be extracted from git describe.

Right now I can't think of a strong reason why that would be a problem. However even sed scripts let you execute arbitrary commands so we would somehow need to sanitise them, which sounds really hard. Bah :-( Any other good suggestions?

from obs-service-tar_scm.

On Dienstag, 21. Juni 2016, 05:31:21 CEST wrote Adam Spiers:

I wrote:

Although this has the limitation of only allowing a single string to be extracted from git describe.

Right now I can't think of a strong reason why that would be a problem. However even sed scripts let you execute arbitrary commands so we would somehow need to sanitise them, which sounds really hard. Bah :-( Any other good suggestions?

Do you allow to inject sed regexp in one of our maintained services?

It is fine to have a personal service running at build time run any scripts though.

Adrian Schroeter
email: [email protected]

SUSE Linux GmbH, GF: Felix Imend�rffer, Jane Smithard, Graham Norton, HRB 21284 (AG N�rnberg)

Maxfeldstra�e 5
90409 N�rnberg
Germany

from obs-service-tar_scm.

Do you allow to inject sed regexp in one of our maintained services?

Not currently, but that was my previous suggestion.

It is fine to have a personal service running at build time run any scripts though.

Yeah, but at build-time is too late for determining the version, and that's the problem we're trying to solve here in a flexible manner. We could support the

<param name="version-command">extract-git-version.sh</param>

feature only for local source service runs, and disable on server-side runs, or do you even see that as a risk?

from obs-service-tar_scm.

@boombatower Now that we merged your commit 960d0ce in #132, is that sufficient, or do we still need something more?

from obs-service-tar_scm.

This is a different issue entirely, but up to you what you want to do with this. Such problems are fun as that commit took two years, hehe. :)

from obs-service-tar_scm.

I'm probably being stupid, but I don't see how it's an entirely different issue - isn't it now possible to accomplish what you originally requested here, using @PARENT_TAG@, @TAG_OFFSET@, and versionrewrite-{pattern,replacement}? If not, please could you explain what's still missing? Thanks a lot!

from obs-service-tar_scm.

I think the original post sums up the idea.

For projects using git it seems to make sense to just use git describe directly instead of including all the parts in the format.

Perhaps %gd (gd = git describe)?

Sure one could use the versionrewrite to drop the v afterwards, but the idea was to use git describe directly. The idea being that the common patterns are either release tags or rolling commit based packages. Rather than have to copy/paste (after finding) or piece together all the parts for such a version why not just provide one built in? Currently, there are a variety of needless subtle differences between such packages including different separator characters like ~, +, etc and different date/commit styles.

If anything this could be re-purposed as simply @ROLLING_VERSION@ which is substitured for some combination of the existing variables like you mention.

from obs-service-tar_scm.