Hey,

Will heap my responses into a single email.

> As another staff member who moderates the AUR (though not as often as
> Fabio), discussion of changes is fair game for this mailing list.

Changes to what? Either:

1. Make the PKGBUILD impossible to audit by the average person, well
that would be a security concern.

2. Lobby for upstream to provide a stable URL, or even go as far as was
done with Discord (seen as Muflone is staff) and see if Arch can get
written permission to redistribute resolve as a package.

Other than that, I do not see what possible outcomes there are to
discuss.

> You're coming at this from a much more aggressive position than the
> OP. There's no indication that OP intends to die on this hill—they
> simply want to discuss the change and whether it could potentially be
> revisited

I meant no aggression. The reason I used "die on the hill" because I
don't see how fetching one file manually is a big enough deal that it
warrants a whole new discussion on a discussion which (as I quoted in
the previous email) had already been done on the AUR comment section.

> I don't see anything wrong with that given the way they've presented
> their arguments. The worst we can say is that we won't change it back.

Never said anything was wrong, just their argument is directly towards
the wrong person. I don't see what Muflone is meant to do, either you
compromise on security or you fetch it yourself. I don't think anyone
here is going to say the former is the better option.

> A fair point, but as you've admitted, Resolve is much more advanced
> than the likes of Shotcut, Kdenlive, etc. If you want a professional
> video editor the likes of Premiere or Sony Vegas on Linux, you need
> Resolve. That's not to knock the FOSS competition in any way, it's
> just reality.

Indeed. Although kdenlive to my knowledge has become a competitive
choice when it comes to video editing (disclaimer I am not a video
editor, this comes purely from discussions with those who are).

> Polarian, I'd like to remind you—as I know others have in the
> past—you are not an AUR moderator. You've engaged in what's called
> "armchair moderation" here, where someone with no power to enforce
> rules attempts to do so anyway.

I have no desire to "enforce rules". As with everyone else subscribed
to the mailing list I have the ability to reply to emails. I think
you have gotten the wrong intent of the email.

My previous email was literally pointing out that the entire discussion
had already been done previously, and cited the comments, there was no
intent of moderation there.

> If you're going to engage in this discussion—and you should feel free
> to do so—please do so constructively and without speaking for the
> Arch staff members that are fully capable of speaking for themselves.

I didn't?

I pointed out that Muflone was a staff member and thus fully understood
the rules. There is a difference between the average AUR maintainer and
a staff member who regularly rules on AUR requests. I wasn't speaking
for Muflone, I was pointing out the AUR package is maintained by
someone who is well know.

I did cite his comments, to show that this discussion was already
discussed and ruled on.

I think you have completely misunderstood the intent of my email, I was
simply trying to help by pointing out what had already been discussed,
not trying to moderate in any way.

> Obviously this does not apply to AUR packages in the same way, because
> the source files are usually stored in an external repository.
> However, for the user, the installation flow is the exact same as if
> the package contained the source files. To expect the user to download
> the actual file is too far; what you have then is not a package, but
> an installation script.

The AUR doesn't provide packages, they provide build scripts for
packages. The only annoyance with this is that you cant use AUR
helpers, but Arch doesn't support these anyways so there's no basis for
argument that breaking AUR helpers would violate the rules.

> I think there is an argument to be made that davinci-resolve is
> unpackageable under a strict interpretation of the AUR guidelines.

Arch Linux is pragmatic, so there should be no "strict interpretation"
they are more guidelines. A PKGBUILD for resolve is better than
nothing, even if it needs manual intervention.

> I'm not averse to the old implementation of the package, though,
> because it was still a package.

No it is a build script, used to build a package.

All the removed changes did was bypassed the annoyances upstream, but
as explained numerous times doing so was difficult to audit, and the
average user, because AUR is build scripts NOT a package, needs to be
able to audit the PKGBUILD before building it, otherwise its a security
threat.

> One thing I could maybe see being done here is approaching Blackmagic
> Design directly in a diplomatic manner to find a solution to
> optimizing this, but since the primary goal of Blackmagic Design
> seems to be the identification of it's users, I am not optimistic
> about how and if we had could come to compromise there. If anything,
> Muflone as the package maintainer is probably the most qualified in
> assessing if such an approach would be useful and to have said
> conversation.

This is usually done by Arch staff (which Muflone is) and it could
indeed be beneficial for an official email to be sent to blackmagic,
like done with Discord. Potentially allowing for not only a stable URL
for source downloading, but also permission to redistribute resolve,
allowing it to be pulled into the repositories in the future.

If Muflone is around maybe they can comment on this, otherwise maybe
someone should ask them directly if they have attempted this yet?

> I apologize in advance when I messed up to answer to this thread,
> since I am new to using mailing lists.

Your reply is good, and I fully agree.

> The download procedure through the support center and through the
> main page is identical. The form is always required for the free
> version, and always optional for the paid one. The support center
> provides access to older versions of the software (and other,
> auxiliary software, like Fusion standalone or the control panel setup
> tooling). I’m certain that Blackmagic doesn’t mind people using it;
> as I stated before my primary reason for going there is acquiring
> older, more bug-free software versions

You have missed the point made again. I do agree that working around
the restrictions put in place by blackmagic is wrong, but the bigger
issue here is the security implications of a complicated script which
must be used to bypass blackmagic, which the average user cannot audit
and thus can't be sure the PKGBUILD is not malicious.

Unless there is a easy URL to get the distributable from, the safest
option is what Muflone has already done, which is to require manual
intervention (download the distributable manually).

I agree, this is not ideal, but security comes first, and there is an
argument also to be made of not causing issues upstream by bypassing
what blackmagic has put in place. The tradeoff is massively outweighed
by the benefits in this case, and thus I still don't see what there is
to discuss here.

> Either way, I do understand the concerns with violating Blackmagic’s
> TOS and license agreements, but I haven’t read them, so I cannot tell
> you.

That is an additional point you are still missing the main point, it is
a security concern. The PKGBUILD IS NOT a package, and must be reviewed
by the average user. Most users do not have indepth knowledge of shell
scripting and thus the bypass can't be audited by the average user.

> I was doing this for some time, but it’s effectively more effort 
> (especially when trying to keep up with fixes to the upstream
> PKGBUILD) than downloading the package manually from Blackmagic’s
> website in the first place.

How long does it feasibly take to download the distributable from
upstream? 1 minute?

In contrast, say if you poorly audited a PKGBUILD and it wiped your
user home directory, how long would that take to recover from?

Security matters far more here.

Take care,
-- 
Polarian
Jabber/XMPP: [email protected]

Reply via email to