Item14208: extender.pl hardcodes Foswiki.org extension repository
Priority: Normal
Current State: No Action Required
Released In: n/a
Target Release: n/a
Applies To: Engine
Component: Configure
Branches:
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
Closing due to inactivity
--
MichaelDaum - 12 Oct 2020