Own Debian repository

[Ninos]

Hey there,

since some months the phpmyadmin package for debian stretch is not updated, so it's still vulnerable for CVE-2018-19968:
https://security-tracker.debian.org/tracker/CVE-2018-19968

Because of that I recommend using an own repository for phpmyadmin packages. Any plans for that? :-)

[nijel]

The Debian package was originally maintained by me and there used to be a PPA with recent packages. I don't have the time for that and nobody was willing to help (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=879741 was filed one and half year ago), so I've given up and dropped the PPA (see https://twitter.com/mcihar/status/1103290188938264576).

There is https://salsa.debian.org/phpmyadmin-team where some initial work was done for packaging libraries, but I have not clue what state is there (besides those being outdated by almost year now).

[MauricioFauth]

I'm interested in helping with maintenance of the Debian package. I've been wanting to do this for a while, but I always end up leaving that aside.

Is it interesting for us to have a debian repository? The same way we have for docker and composer.

[ibennetch]

Having our own repository would allow us to offer better updates than the Debian hierarchy allows, but we'd have to be careful about dependency versions (for instance, if we no longer support MySQL prior to version 8, but most Debian repositories only contain version 5.7). I'm neutral on this idea, I'm not really in favor or against it.

[nijel]

There are repositories to bring recent PHP or MariaDB versions on Debian, those people would use having recent phpMyAdmin as well. For example see oerdnj/deb.sury.org#1131

The reason for having own repo is that Debian Buster will ship without phpMyAdmin and people will look for installing it there. The alternative approach might be to introduce it there through backports.

[Ninos]

For such applications an own repository makes sense, because of faster releasing of new versions. phpmyadmin is non-critical for the system and normally can be updated to newest stable releases. Gitlab is also another good example for having an own repository.

[e-gaulue]

Debian is rather known to be serious but not really reactive. By serious, I mean also rather secure and usable for a production environment.

Not having a package in Debian repository looks just crazy to me. If not coming through Debian backport or by an official own phpmyadmin repository, this means lots will install phpmyadmin on their own (you begin to find recipes about it if you google "phpmyadmin buster"). Sadly, just few of them will really follow the project, and the majority will forget, keeping an old version without paying attention to its security as long as it works.

@ibennetch Having your own repository leaves you free to be stricter than Debian regarding version support (just have to explain this in an introduction web page, anyway users will see it as it's set in package version dependencies), and allow you provide a distribution you consider reliable and sure. I don't say it's easy, but usually once the scripts are good it's rather automatic.

So for me, as a system administrator, I'm not neutral. This situation is the worst for me: no package in Debian repository and no "official" phpmyadmin repository.

Buster is not officially stable right now. I do not know much about the Ubuntu/Debian relationship, but Ubuntu should follow the Debian position... This should awake the claim.

[williamdes]

cc @Blaimi

[Blaimi]

Hey there,

I've made some progress recently packaging the current version for the upcoming buster release as well as backporting the PMASA back to stretch and jessie on salsa.debian.org.

the work ist based on work from @fsateler and @gratuxri.

@williamdes started reviewing the mergerequests and did already some upstream patches. we (@krumedia) also did a bionic backport for internal use which is working — at least for the simple basic operations we uns on our dev-machines.

To come forward, we need a Debian Developer as Mentor for uploading the Package into the official repositories. Maybe @fsateler can help with that.

Reviews and Testing of the merge-requests on salsa are very welcome. I am looking forward to create a ppa during the next for easier testing.

[Blaimi]

Here we go: https://launchpad.net/~phpmyadmin/+archive/ubuntu/ppa

[Ninos]

Is it still planned to use own repository? I recommend that instead of uploading to debian default repository (in past we already had this problem, because of that I created this issue) :-)

[Blaimi]

What do you mean with “own”? Owned by @phpmyadmin on github or a repository for packages separated from this one? 😉 And what was the problem? The main problem in the past 1.5 years was, that noone was found to maintain the packaging — that's nothing a separate repository could fix 😉

If you mean only to be separated, the repository on salsa ist perfectly fine. Its purpose is only for the debian packaging part of the project and intergates fine into the debian CI.

Packaging for Debian is way more than knowing the project itself but much more about knowing how Debian and its politics work. While I have been creating packages for years now (internal use only), I still have to learn a lot.

Using salsa is IMO the best way to maintain the package. Anyone who wants to contribute is welcome and can create mergerequests, issues or have access to the repository. Having an additional separate repository will only make sense if you do not want to follow the the dfsg or violate the debian policy (e.g. by including libraries like openlayers or any composer package in the package). Gitlab does that for example: you can gitlab as debian package from debian or from gitlab — they have not very much in common except they are based on the same sourcecode. These packages will never be accepted in the main repository but can have more recent versions.

If you want to know more about the current state for the upcoming buster release, please have a look at https://salsa.debian.org/phpmyadmin-team/phpmyadmin/issues/1

[Blaimi]

or do you mean debian repository instead or git repository? The ppa should do the job also for buster since the code is the same.

EDIT: yes, TL;DR; 🙄

[Blaimi]

TL;DR;

Even with my misunderstanding there are still arguments which are valid:

The main problem in the past 1.5 years was, that noone was found to maintain the packaging — that's nothing a separate repository could fix.

Packaging for Debian is way more than knowing the project itself but much more about knowing how Debian and its politics work. While I have been creating packages for years now (internal use only), I still have to learn a lot.

comments

phpmyadmin is non-critical for the system

I don't think so. pma is installed on thousands of servers and a defacto-default on any LAMP-installation. I am with you in the context of having bugs in a software only useful for developers which can always use a different tool (like CLI) but absolutely not with you in the context of bugs in a software which can give malory direct access to databases and execute plain sql which would not be possible if the software is not installed. I assume +90% of the installations are used for the one and only 'localhost' and are not secured by any other techniques than the login with sql-server-credentials. that's why there are bots who check for wordpress-security-issues to grab the server-config (including the db-password) and login to the database using pma.to manipulate wp_posts.

Gitlab is also another good example for having an own repository.

I'd not say “good” on that. Have you ever used it? The package even brings its own postgresql-server. These packages are IMO only useful for playgrounds and not production-environments. And do not even try to uninstall the package. It installs configurations and services and tons of stuff everywhere on the system and has no uninstall routine.

Buster is not officially stable right now. I do not know much about the Ubuntu/Debian relationship, but Ubuntu should follow the Debian position... This should awake the claim.

I'm not really sure about that. They still ship pma 4.6 in bionic which has an error as first impressions after login. they are also shipping mysql5.7 in disco bit mysql was not even available in stretch.

I'm not sure about the coming up 'eoan' but I'm absolutely confident to get the new version to 20.04 which is the next LTS after bionic (name?)

ppa

So, in the meanwhile I did not only overcome my lazyness and read the whole issue but also tested the ppa on buster.

I could install phpmyadmin with the following workflow:

apt-get install gnupg
apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 42YOUWILLKNOWWHERETOGETTHEFINGERPRINT45
wget http://ftp.de.debian.org/debian/pool/main/p/php-symfony-polyfill/php-symfony-polyfill-mbstring_1.9.0-1_all.deb
dpkg -i dpkg -i php-symfony-polyfill-mbstring_1.9.0-1_all.deb
apt-get install -fy
echo 'deb http://ppa.launchpad.net/phpmyadmin/ppa/ubuntu bionic main' > /etc/apt/sources.list.d/phpmyadmin-ppa.list
apt-get update
apt-get install default-mysql-server apache2
apt-get install phpmyadmin

This has some problems:

• php-symfony-polyfill needs to be installed manually. (I can fix that by uploading a version to the ppa)
• the ppa is meant for bionic, not for buster. launchpad does either not allow to pusblish packages for non-ubuntu series or I don't know how. (I can remember this was possible in the past but can't find any documentation about it, https://help.launchpad.net/Packaging/PPA/Uploading says, you can upload for any dpkg-based distribution but publish only for ubuntu-series?)
• the packages in the ppa have been built in a very "unstable" environment by myself. There is no automation which makes it very hard to upload updates – that's why the ppa says Do not use these packages on production!
• People will install the packages from there and never switch to backports. This would not be a problem if the packages are always the same but I think they will not (see
• above) and I am not willing to change this (maybe someone else?).

own repo?

From the end-user-perspective this has one main advantage: It makes it easy to install pma from an pma-'official' channel for debian and maybe it's derivates.

So, having an own debian-repository leads to one important question:

Do you want to have the same versions as in debian – or even be compatible/interchangeabe – or do you want to make a package independent/conflicting the debian one (gitlab-way)

compatible

has the same packages as debian has. packages comes from the same maintainers

advantage

• updates could be deployed faster than them from debian
  • this should not be the case if the packages are actively maintained.
    • if the package is not maintained, you will probably not have a new version for your own repo
• versions could be more recent for older debians
  • that's what debian-packports are for

disadvantages

• needs to maintain a complex debian-repository
• forces the maintainers to not only maintain packages for debian but also for the pma-debian-repo
• not only pma-packages have to be published but also some of it's dependencies (see phpmyadmin-team on salsa)

incompatible

has own versions of phpmyadmin in it's own repository

advantages

• is not forced to follow dfsg
  • not following the dfsg is not really an advantage but in case of pma it makes things sometimes easier
  • this means you don't have to repack the sources-package only because of the jslint-“not evil”-license
• does not have to follow debian policy
  • this means you don't have to create a package for each dependency and are not forced to use the libraries which are already available in debian
• because of not following the debian policy you can build a 'one size fits all derivates'-solution because you can bring your own versions of dependencies. E.g. “twig 1, twig 2? who cares, we can bring the version we want”
• MAY (as in RFC2119) have different maintainers.
• packages can be easily built with each tag using travis
• repository-structure is very easy because you don't have to care about series like 'buster', 'disco', 'tessa', …

disadvantages

• increases the effort of packaging for debian
  • but I think the increase is less than on the compatible way
• package features may differ

must have

• it's own repository (and yes, this time I mean a git repository :D ) for the debian-part
  • not really a must have but I think this keeps things clean
• a different name than the debian-package
  • it would be horrible to have two packages with very different contents and dependencies conflicting and/or replacing each other
  • I don't know since when and why the phpmyadmin-package has the epoch-version 4, but this could be one way on how to get them
• complete CI integration. this means tag -> package -> repository

nice to have

• packages for download which automatically install the repository. That's what e.g. googe-chrome is doing. this is a known workflow for people coming from "hey, you need to find, download and update and update and update and … every software manually"-ecosystems.

conclusion

• Maintaining a debian-repo is much work
• If you still want to have an own repo, I'd recommend the incompatible way
• to not get completely different packages and to be able to share the knowlege, the maintainers SHOULD be the same people but MAY differ

If someone of the phpmyadmin-team is willing to do the stuff around the CI/Travis (building, hosting, signing, etc) I can create the debian-part to create a package based on the *source.tar.gz-artifacts which includes all the dependencies and should be able to be installed on all debian-derivates which have a compatible php-version.

[Blaimi]

ah, I forgot to mention the alternatives: snap and flatpak. These formats are especially invented to include all the dependencies and libraries in a single package and to be distribution-independent. I don't know much about how they fit for webapplications which require connections to sql-servers but it deserves a chance.

I am using them only for desktop-applications (intellij, skype, firefox nightly) and cannot help on that topic. I even could not find any similar app on a quick view in snapstore or on flathub.

[Ninos]

I don't think so. pma is installed on thousands of servers and a defacto-default on any LAMP-installation. I am with you in the context of having bugs in a software only useful for developers which can always use a different tool (like CLI) but absolutely not with you in the context of bugs in a software which can give malory direct access to databases and execute plain sql which would not be possible if the software is not installed. I assume +90% of the installations are used for the one and only 'localhost' and are not secured by any other techniques than the login with sql-server-credentials. that's why there are bots who check for wordpress-security-issues to grab the server-config (including the db-password) and login to the database using pma.to manipulate wp_posts.

Same opinion, I meant it's non-critical for the system itself, if application is not running anymore because of a bug in update (only application is not running anymore, there's no dependency to other applications).

About the security issues, you're completely right, because of that I opened this issue. phpmyadmin should definitely be available via debian repository (debian or own doesn't matter), otherwise we'll have lots of unpatched instances.

The reason why I thought about an own debian repository is following security issue:
https://security-tracker.debian.org/tracker/CVE-2018-19968
For Debian Stretch it's still not fixed. One of the reasons could be, that debian only accepts security patches, which needs be be done for each debian version separetely (takes time). If you have your own debian repository you could deploy every version (e.g. on stable branch) to your repository automatically, doesn't matter what you added (security fixes, features, ui changes).

[Blaimi]

I merged https://salsa.debian.org/phpmyadmin-team/phpmyadmin/merge_requests/6/ into the stretch branch so we can upload the package with the fix.

[Blaimi]

BTT: I will not have time to create a package until next week, but maye someone wants to create a new (and empty, i.e no initial empty commit or readme or license …) repository like github.com/phpmyadmin/debian.git and add me as a developer in the meanwhile.

building the package from native format (like in a debian branch in the main repo) is no option because including all the dependencies is not possible.

Ah, and we would have to find a new package-name 😉 how about phpmyadmin-omnibus 😃

[Blaimi]

hah, nextcloud is also distributed as snap

https://github.com/nextcloud/nextcloud-snap
https://snapcraft.io/nextcloud

the problem with adopting the package is that it brings it's own mysql-server. Having an own apache is not very resource-friendly but would not be a big deal if we don't use port 80 (or 443) and force any user to setup a reverse-proxy in the 'main apache-instance' (or nginx or lighhttp or whatever). We should also be able to use something more leightweight like an nginx. Having it's own mysql is the big deal since phpmyadmin without access to any database except it's own makes the software very useless.

the nextcloud-snap has also 122 open issues in the time of this writing. many of them are not related to nextcloud or its snap-package itself but for the correct handling on snap, apache, redis and other stuff. (there are only 5 open issues with the label 'bug'). I don't think a potential pma-snap would have the same ratio on support-issues to real bugs because pma doesn't have plugins, but you will have to deal with new problems coming from snap users.

conclusion:

• is it possible to have a snap package which connects to a mysql server outside of the box?
  • EDIT: my intellij-snap can connect to foreign sql-servers, so delivering the nextcloud-snap with its own sql-sever cannot be because of a restriction of snap …
• snap is more flexible than an own debian-repo. It's Distribution-Independent and brings even the runtimes it needs – basically php. This would make it possible to install pma 5.0 on php7.0-based stretch or even php5.6-based jessie or php5.4-based CentOS7
• you will have to deal with a new technology and a new user-group. I assume this will need a similar effort on maintenance as the docker-image.

[Blaimi]

some links:
https://www.github.com/blaimi/phpmyadmin-debian-omnibus
https://launchpad.net/~phpmyadmin/+archive/ubuntu/ppa/

I also added tcpdf and php-symfony-polyfill to the phpmyadmin ppa

the omnibus-package cannot (yet?) be installed on jessie because the php-package-names have changed from php5-* to php-*. I don't know yet if I'll ever find the motivation to do this …

EDIT: The upload of php-symfony-polyfill is not done yet. The package cannot build because of a version-mismach of phpunit. I will have to wait until the deletion of the current package is done so I can upload a version with a ~ppa-suffix and disabled tests.

[helmo]

Thanks for working on this!

I've installed it on a test Debian Buster VM and it works nice.

I'm also trying this on a test Debian stretch VM, but it's missing the php-psr-container package.
I've manually added it from the buster repo

Then it's still missing a part of Twig (1.24.0-2+deb9u1 of php-twig is installed).
PHP Fatal error: Uncaught Error: Class 'Twig\\Loader\\FilesystemLoader' not found in /usr/share/phpmyadmin/libraries/classes/Template.php:61

[Blaimi]

the new version of pma is not planned to be released for debian stretch. debian stretch has a working phpmyadmin-package. Since stretch is now oldstable it's not worth the effort to get any new version into backports.

Our goal at the moment is to get the package as fast as possible into buster-backports. For ubuntu 18.04 the ppa is working and we maybe can get it also into bionic-packports. The effort here is worth it because the current bionic-package is broken (pma 4.6.6 does not support php7.2 from bionic but 7.0 from stretch)

the twig-problem is obvious. the twig-extension-package brought you by the ppa is based on twig2 but stretch has twig1

[MESWEB]

apt-get upgrade php-tcpdf php-twig
Installed successfully but phpmyadmin still see error:
phpmyadmin : Depends: php-twig (>= 2.9) but 2.6.2-2 is to be installed Recommends: php-bz2 Recommends: php-zip

[williamdes]

Hi @MESWEB
Please try #15236 (comment) (apt-get install php-twig=2.12.5-1~bpo10+1)

[MESWEB]

@williamdes

Building dependency tree
Reading state information... Done
E: Version '2.12.5-1~bpo10+1' for 'php-twig' was not found

Could you please write bash script for automated installation of phpmyadmin. You can call it like debian10installation.sh and put this file into phpmyadmin directory. This script will download latest version an do all installation process.

[williamdes]

@williamdes

Building dependency tree
Reading state information... Done
E: Version '2.12.5-1~bpo10+1' for 'php-twig' was not found

Could you please write bash script for automated installation of phpmyadmin. You can call it like debian10installation.sh and put this file into phpmyadmin directory. This script will download latest version an do all installation process.

Please try apt-policy twig to view the available packages for backports and be sure to have added buster-backports and updated apt lists

[pjotrek-b]

First of all: Thank you very much for making phpmyadmin available through backports! 🍰
Not because of convenience, but because I believe that server maintenance profits greatly from unified basic installation processes from common/official sources. I was very surprised to see phpmyadmin missing in Debian Buster repos.

Regarding the php-twig installation, here's what worked for me:
$ apt install -t buster-backports php-twig

[williamdes]

apt update && apt install -t buster-backports phpmyadmin

And you will have phpMyAdmin 5.0.4 🚀

Enjoy and open new issues for any question or bug found

Happy new year and enjoy the new version!

[williamdes]

This is near to the one year anniversary of this event ! 🎉
I am proud to announce that you can install phpMyAdmin 5.1 in Debian bullseye from bullseye-backports 🚀

Using Debian bullseye

deb http://deb.debian.org/debian bullseye-backports main

upgrade or install

apt upgrade -t bullseye-backports phpmyadmin

or

apt install -t bullseye-backports phpmyadmin

Happy new year and enjoy the new version!

You may find other ways on the Wiki for install methods on Ubuntu/Debian

[OlafvdSpek]

Nice, thanks a lot William!

[williamdes]

Thanks to some help for the upload of php-twig, I am so happy to finally announce the availability of phpMyAdmin 5.2.1 on bullseye-backports 🎉 !

See: https://tracker.debian.org/news/1428174/accepted-phpmyadmin-4521dfsg-1bpo111-source-into-bullseye-backports/
See: https://packages.debian.org/source/stable-backports/phpmyadmin

Add this source

deb http://deb.debian.org/debian bullseye-backports main

apt update
apt policy phpmyadmin
apt install -t bullseye-backports phpmyadmin