Item14208: extender.pl hardcodes Foswiki.org extension repository

pencil
Priority: Normal
Current State: Waiting for Feedback
Released In: n/a
Target Release: n/a
Applies To: Engine
Component: Configure
Branches:
Reported By: FlorianSchlichting
Waiting For:
Last Change By: FlorianSchlichting
Extensions can specify the repository where they originate in their installer using $PACKAGES_URL, which is passed as

Foswiki::Extender::install( $PACKAGES_URL, 'MyFancyPlugin', ...

Since df238af1ca96ddf498cca18d1f5a2e59ea7184de (Item13391: Major refactor of extender.pl and tools/configure), this doesn't work any more, as extender.pl hardcodes "Foswiki.org" as the key with which tools/configure will look up the repository URL from $Foswiki::cfg{ExtensionsRepositories}

I haven't investigated how hard it would be to enable tools/configure to work with a URL in addition to the currently used key. Limiting possible extension repositories to those configured in LocalSite.cfg may be a security feature. And alternative/local extension repositories are probably not that common anyway.

What would work for me is requiring local extensions to change and pass a valid key, and defaulting to "Foswiki.org" otherwise:

--- a/core/tools/extender.pl
+++ b/core/tools/extender.pl
@@ -190,7 +190,8 @@ sub install {
 "Do you want to use locally found installer scripts and archives to install $MODULE and any dependencies.\nIf you reply n, then fresh copies will be downloaded from this repository."
     ) unless ($reuseOK);
 
-    @ARGV = ( '-wizard', 'InstallExtensions', '-args', "$MODULE=Foswiki.org" );
+    $PACKAGES_URL = 'Foswiki.org' if $PACKAGES_URL eq 'http://foswiki.org/pub/Extensions' or ! $PACKAGES_URL;
+    @ARGV = ( '-wizard', 'InstallExtensions', '-args', "$MODULE=$PACKAGES_URL" );
 
     push @ARGV, (qw( -args USELOCAL=1)) if ($reuseOK);

That way, no changes would be necessary in the common case, and local repositories would again be possible. However, the variable "PACKAGES_URL" should probably be renamed in both extender.pl as well as the installer template from BuildContrib.

-- FlorianSchlichting - 02 Nov 2016

Since this is a command line tool, any protections gained by forcing use of a configuration key is probably useless. But indeed a function has been lost here.

The extender.pl does report the command used to install an extension. As this is more direct access to the tool, it is probably preferred. By using the InstallExtensions wizard directly, you can override the repository

tools/configure -save -set {ExtensionsRepositories}='Mysite.org=(https://foswiki.org/Extensions/,https://foswiki.org/pub/Extensions/)' -wizard InstallExtensions -method add -args FoobarPlugin=Mysite.org

Only if the install succeeds will the settings be saved, and it will save a new ExtensionRepositories key along with any changes caused by merging the Config.spec

Renaming the variable in the extender and template would need further investigation as we still want all the extensions installable on older Foswiki.

-- GeorgeClark - 12 Nov 2016

I think I might have an alternative fix. This allows the PACKAGE_URL to be inserted into the front of the repositories list. I'm not sure it's really advisable, This could allow a package file downloaded from "site 1" to then pull the archive down from a different site. So this needs a review with a close look at security implications.
diff --git a/core/lib/Foswiki/Configure/Wizards/InstallExtensions.pm b/core/lib/Foswiki/Configure/Wizards/InstallExtensions.pm
index f45175e..08940f8 100755
--- a/core/lib/Foswiki/Configure/Wizards/InstallExtensions.pm
+++ b/core/lib/Foswiki/Configure/Wizards/InstallExtensions.pm
@@ -59,15 +59,34 @@ sub _getPackage {
 
     my $args = $this->param('args');
 
+# $repo can either be a Key in the repository config,  or it can be a URL.  If it looks like a URL
+# then create a compatible repositories hash, and push the URL location into the front of the list.
+
     my $repository;
-    foreach my $place (
-        Foswiki::Configure::Wizards::ExploreExtensions::findRepositories() )
-    {
+    my @repolist =
+      Foswiki::Configure::Wizards::ExploreExtensions::findRepositories();
+
+    if ( $repo =~ m/^https?:\/\// ) {
+        $repo .= '/' unless ( $repo =~ m#/$# );
+        unshift(
+            @repolist,
+            {
+                name => $repo,
+                data => ' Local Override',
+                pub  => "$repo",
+                user => undef,         # Could be added in future
+                pass => undef
+            }
+        );
+    }
+
+    foreach my $place (@repolist) {
         if ( $place->{name} eq $repo ) {
             $repository = $place;
             last;
         }
     }
+
     if ( !$repository ) {
         if ( $args->{USELOCAL} ) {
             $reporter->WARN( "Repository not found: $repo",

Crawford, any thoughts? Given that BuildContrib puts PACKAGE_URL in every installer package, it means that CLI installation using the executable package will always use the URL contained in the package.

-- GeorgeClark - 15 Nov 2016

The patch to InstallExtensions.pm alone is not enough, or I haven't understood how you meant it to be used - I usuallly execute the installer, which does do tools/extender.pl and then the above call to Foswiki::Extender::install(). This ends up doing

tools/configure -save -wizard InstallExtensions -args MyFancyPlugin=Foswiki.org -method add -args ENABLE=1

Which fails with
#### ERROR: Download failed - I can't download http://foswiki.org/pub/Extensions/MyFancyPlugin/MyFancyPlugin_installer because of the following error:
Not Found

#### ERROR: The Extension may not be usable due to errors. Installation terminated.

-- FlorianSchlichting - 12 Dec 2016

I think the patch is dangerous, for the reason given by George.

tools/configure -save -set {ExtensionsRepositories}='Mysite=(https://mysite/Extensions/,https://mysite/pub/Extensions/)' -wizard InstallExtensions -method add -args FoobarPlugin=Mysite

ought to work; given that local repositories are not a common requirement, I don't see the problem with this.

-- Main.CrawfordCurrie - 09 Jan 2017 - 18:26

I'm not sure I understand where this leaves us; would it be a correct summary to say

"If you have extensions from a local repository, simply executing the installer does no longer work on Foswiki 2. Instead, call tools/configure directly while setting the ExtensionsRepositories key, as in the example above."

-- FlorianSchlichting - 18 Jul 2017
 

ItemTemplate edit

Summary extender.pl hardcodes Foswiki.org extension repository
ReportedBy FlorianSchlichting
Codebase
SVN Range
AppliesTo Engine
Component Configure
Priority Normal
CurrentState Waiting for Feedback
WaitingFor
Checkins
TargetRelease n/a
ReleasedIn n/a
CheckinsOnBranches
trunkCheckins
masterCheckins
ItemBranchCheckins
Release02x01Checkins
Release02x00Checkins
Release01x01Checkins
Topic revision: r6 - 18 Jul 2017, FlorianSchlichting - This page was cached on 12 Sep 2020 - 19:13.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy