Possible Proxy Issue

[stoffel2]

Premise

"AM"/"AppMan" is just a tool to provide applications easily and quickly and is only responsible for integrating the AppImages into the system and installing the various programs available, respecting the following order (refer to the option "-d" to download the installation script without installing it):

• creation of the base directories and the removal script
• download of the package
• creation of the version file and the update script
• possibly, extraction of the icons and .desktop files, if needed

The malfunction of the installation scripts will then be taken into account. On the contrary, any malfunction related to individual applications is the responsibility of the related developer or packager. Refer to the option "-a" to know the sources of each program listed here, so you can contact them to report the bug.

---

Please, describe the bug

I am working behind a proxy on a debian 13 system.

I have set the proxy in /etc/wgetrc and /etc/profile.d/proxy.sh but when I use "appman -l" I get an empty list.

Is there perhaps another proxy location appman might be using to download the DB?

Chris

[ivan-hc]

The only proxy in use is this one

AM/APP-MANAGER

Line 1396 in 5c126c7

[ -z "$ALT_GH" ] && ALT_GH="https://api.gh.pkgforge.dev"

...but it has nothing to do with -l. It is used in -i, -u (for the apps) and -t only.

This is how AM updates its main list (the one of apps in the AM database only)

AM/APP-MANAGER

Line 677 in 5c126c7

curl -Ls "$APPSLISTDB" 2>/dev/null | grep "^◆" > "$AMDATADIR/$ARCH-apps"

Where APPSDB is this

AM/APP-MANAGER

Line 543 in 5c126c7

export APPSLISTDB="$AMREPO/programs/$ARCH-apps"

...and AMREPO is this

AM/APP-MANAGER

Line 6 in 5c126c7

AMREPO="https://raw.githubusercontent.com/ivan-hc/AM/main"

About $ARCH, only x86_64, aarch64 and i686 are supported for now

https://github.com/ivan-hc/AM/tree/main/programs

From how much time you have this issue?

[stoffel2]

It was the curl call (Line 677) that was the problem. I created a user .curlrc file with the proxy entry. In this case I am on a Debian VM which relies on a proxy-server for access to the internet.

Thanks!

[ivan-hc]

It was the curl call (Line 677) that was the problem. I created a user .curlrc file with the proxy entry. In this case I am on a Debian VM which relies on a proxy-server for access to the internet.

Thanks!

This one?

AM/APP-MANAGER

Line 677 in 753bb71

curl -Ls "$APPSLISTDB" 2>/dev/null | grep "^◆" > "$AMDATADIR/$ARCH-apps"

It is the one that reads the apps list (for x86_64 is this one) and prints it to the local list.

Is there something I can do?

[stoffel2]

yea, that seems to be where you use curl to get the list of apps. Unfortunately, Debian has several programs that each have their own proxy settings (i.e. apt, get, curl, ....), and that don't seem to care if you have set a proxy env variable set.

You could just add a line to your setup instructions saying that if you are behind a proxy-server you need to enter it in your .curlrc file for appman to be able to download the list. There might be a better way of doing this, I'm not an expert.

[ivan-hc]

I'm on Debian, but I don't use proxies... and seems strange to me this behavior.

Would it be different if you replace curl -Ls with wget -q -O -?

[stoffel2]

It is in fact a pain, even the browsers seem to have their own proxy settings. I have no idea why, and there does not seem to be any effort to change that in Debian.

It would help if you only used wget and not both wget and curl. Then only one proxy would have to be set (for wget). But still, it might not be an issue for very many. I'd just mention that the proxy must be set in wget and curl.

[ivan-hc]

Can your settings imported in AM trough variables?

[ivan-hc]

Can your settings imported in AM trough variables?

I mean, it would ideally to allow AM using your settings somehow.

[stoffel2]

Sure, for instance if an env proxy variable was defined, you could pass it to curl. But I think it would be easier to have the user deal with the proxy settings, telling them that they need to set the proxy variables for wget and curl would resolve the issue. It is easy to find out how to do that:

wget: https://stackoverflow.com/a/11211812/29051306

curl: https://stackoverflow.com/a/35815181/29051306

[ivan-hc]

I don't know much about this stuff.

Anyway, to warn the user about the issue, I need a check for this problem that would come up.

I dedicated a whole section in the main script for all troubles a user would have in various situations. Each header says what the function does 👇

AM/APP-MANAGER

Lines 408 to 492 in 1ed6860

	################################################################################################################################################################
	# SECURITY
	################################################################################################################################################################
	# SAFETY CHECKS
	_am_dependences_check() {
	# Check for essential commands required by the application
	missing_deps=""
	AMDEPENDENCES="cat chmod chown curl grep sed wget"
	for name in $AMDEPENDENCES; do
	if ! command -v "$name" >/dev/null 2>&1; then
	missing_deps="$name $missing_deps"
	fi
	done
	# Exit if any essential command is missing
	if [ -n "$missing_deps" ]; then
	echo "$DIVIDING_LINE"
	printf $" ${RED}💀 ERROR! MISSING ESSENTIAL COMMANDS\033[0m: %s\n\n Install the above and try again! \n" "${missing_deps[*]}"
	echo "$DIVIDING_LINE"
	printf $"%bList of the %b core dependences\033[0m:\n\n%b\n" "${Green}" "$AMCLIUPPER $AMVERSION" "$AMDEPENDENCES" | _fit
	echo "$DIVIDING_LINE"
	printf $"If this message appears it is because you are missing some dependency and if its the first time its because something new has been introduced.\n\n" | _fit
	printf $" See %bhttps://github.com/ivan-hc/AM#core-dependences\033[0m for more information\n" "${LightBlue}"
	echo "$DIVIDING_LINE"
	exit 1
	fi
	}
	_check_fedora_mess() {
	if wget --version | head -1 | grep -qi ' 2.\|wget2 '; then
	printf $"\n%bWARNING: your distro maintainer ships \"wget2\" as \"wget\" \033[0m\n\n" "${RED}" | _fit
	[ -f /etc/redhat-release ] && printf $"Please install \"%bwget1\033[0m\" and \"%bwget1-wget\033[0m\" (use %b--allowerasing\033[0m if you have to)\n\nSee https://bugzilla.redhat.com/show_bug.cgi?id=2358792\n\n" "${Gold}" "${Gold}" "${Green}" | sed "s/^/ /g"
	fi
	}
	_check_ubuntu_mess() {
	if command -v unshare >/dev/null 2>&1 && ! unshare --user -p /bin/true >/dev/null 2>&1; then
	echo "$DIVIDING_LINE"
	printf $"\n %b⚠️ WARNING: ACCESS TO USER NAMESPACES IS RESTRICTED! \033[0m\n\n" "${RED}"
	echo $" Some apps may not run, you need to enable access to user namespaces, see"
	printf " %bhttps://github.com/ivan-hc/AM/blob/main/docs/troubleshooting.md#ubuntu-mess\033[0m\n" "${LightBlue}"
	echo $" to know more."
	echo ""
	echo "$DIVIDING_LINE"
	fi
	}
	_am_dependences_check
	_check_ubuntu_mess
	# Function to check online connections (uses github.com by default, as the database and CLI itself are stored/hosted there)
	_online_check() {
	if ! wget -q --tries=10 --timeout=20 --spider https://github.com; then
	printf $"\n %b is offline, please check your internet connection and try again\n\n" "$AMCLI"
	exit 0
	fi
	}
	# BLACKLIST FILES
	appimagelauncher_msg="Your installation of AppImageLauncher may have been done via DEB, RPM, or AUR, which interrupts the natural operation of \"systemd-binfmt\" in addition to launching the aforementioned daemon. To avoid problems with \"$AMCLIUPPER\" and any other AppImages helper, it's preferable to use \"only\" the standalone AppImage of AppImageLauncher, whose official updated release can also be installed via \"$AMCLIUPPER\". But as long as you have the currently installed version, you can't use this CLI."
	_blacklisted_file() {
	printf $"\n %b💀WARNING! Detected \"%b\"\033[0m\n\n" "${RED}" "$blacklisted_file"
	echo $"It will prevent \"$AMCLIUPPER\" from working correctly with AppImages, especially when extracting, integrating and updating them." | _fit
	echo ""
	if echo "$blacklisted_file" | grep -q appimagelauncherd; then
	echo "$appimagelauncher_msg" | _fit
	echo "" && echo $" Please remove \"AppImageLauncher\", reboot and retry!"
	else
	echo $" Please remove \"$blacklisted_file\", reboot and retry!"
	fi
	echo ""
	exit 0
	}
	if command -v appimaged &>/dev/null; then
	blacklisted_file=$(command -v appimaged)
	_blacklisted_file
	elif command -v appimagelauncherd &>/dev/null; then
	blacklisted_file=$(command -v appimagelauncherd)
	_blacklisted_file
	fi
	################################################################################################################################################################

[Samueru-sama]

I would really try to use wget instead of curl as much as possible.

here I don't think there is even a problem given that there is no progress bar here right?

[ivan-hc]

I would really try to use wget instead of curl as much as possible.

here I don't think there is even a problem given that there is no progress bar here right?

It is not a problem at all.

curl vs wget is a "clash between parties" after all. I also prefer wget, but the more commonly used is curl in many cases.

Obviously there are distros that want do things more complicated (see Ubuntu that plans to remove wget and Fedora that has already done the mess)

[stoffel2]

There seem to be a few threads comparing wget and curl, they seem to have different uses. If there is no need for curl per se, I'd say don't use it.

My suggestion: use wget to install your script, as well as to update your DB, When the user behind a proxy tries to install, they will realize that they need to set the proxy for wget, and the DB download will also work.

[ivan-hc]

But curl -Ls is used also inside the installation scripts

[stoffel2]

But curl -Ls is used also inside the installation scripts

? Sorry, but I don't understand.

[ivan-hc]

Sorry, I have not understand... if setting is for APT, why the whole system is involved?

[stoffel2]

Look, if a system is behind a proxy it can't reach the internet. In Debian you need to, unfortunately, set the proxy for every program that wants to access the internet (Browser, apt, wget, curl, etc). Users will usually be aware of this and in most cases have at least set the proxy for apt. You could theoretically pull this information and pass the proxy to wget and curl in your script.

This is complicated because some proxy-servers also require user validation. I'm no expert on how to do this most effectively, which is why I suggested simply informing your users that they will have to provide their proxy settings to curl and wget for your scripts to work.

I'm actually kind of surprised that no one has written a script to add the proxy-data to all the various programs in Debian. I guess it's not that common of an issue.

[ivan-hc]

In all my years of using Debian, I've never had this problem, and this seems like a niche issue, so it's hard for me to even figure out how to proceed. I risk sending messages and instructions to people who, basically, don't have this problem.

I need to be sure how to proceed.

[stoffel2]

I'm fine with that.

[RafaelLinux]

I'm also using a proxy that requires authentication on my intranet, but I use openSUSE, so I configure all the proxy settings from YaST and Plasma's preferences (each has its own interface). With the correct configuration, I have no problems listing, installing, or updating applications with "appman".

[ivan-hc]

My suggestion: use wget to install your script, as well as to update your DB, When the user behind a proxy tries to install, they will realize that they need to set the proxy for wget, and the DB download will also work.

@stoffel2 I have an idea on how to do this.

If you open an installation script you will see something like this

version=$(curl -Ls https://api.github.com/repos/REVENGE977/stremio-enhanced/releases | sed 's/[()",{} ]/\n/g' | grep -oi "https.*mage$" | grep -vi "i386\|i686\|aarch64\|arm64\|armv7l" | head -1)
wget "$version"

Here is where is used curl -Ls, to read the pages. wget is used to download the reference.

In this case, if...

ivan@debian:~$ curl -Ls https://api.github.com/repos/REVENGE977/stremio-enhanced/releases | sed 's/[()",{} ]/\n/g' | grep -oi "https.*mage$" | grep -vi "i386\|i686\|aarch64\|arm64\|armv7l" | head -1
https://github.com/REVENGE977/stremio-enhanced/releases/download/v1.0.1/Stremio.Enhanced-1.0.1.AppImage

then the download command will be

wget https://github.com/REVENGE977/stremio-enhanced/releases/download/v1.0.1/Stremio.Enhanced-1.0.1.AppImage

The curl -Ls alternative is wget -q -O -, this means that, in case of a specific configuration, I can add a sed command in the install.am module, that does this

sed -i -- "s/curl -Ls/wget -q -O -/g" ./"$arg"

...where $arg is the installation script to patch.

@RafaelLinux you suffer this issue with shutter encoder, which script contains this

version="https://www.shutterencoder.com/Shutter%20Encoder%20$(curl -Ls "https://api.github.com/repos/paulpacifico/shutter-encoder/releases/latest" | sed 's/[()",{} ]/\n/g' | grep -oiE "tag/([0-9.]+)" | sed 's/tag\///')%20Linux%2064bits.AppImage"
wget "$version"

As always, curl -Ls to read the reference (in this case is a tag) and wget to download the reference.

---

Question

What to check in a if statement to use such function?

What your systems have of so different from mine and other's?

Let me know.

[RafaelLinux]

I tested both parameters (curl and wget). As I suspected, curl requires changes to its configuration file to work in proxy environments, while wget can retrieve the file directly. curl -O "$version" retrieves nothing and, depending on the case, displays an error upon completion. I can't find a clear reason why some fail (shutter-encoder) and others don't (stremio). I can download both files using their URLs in a web browser (after entering my proxy username and password). In other words, both are accessible from the web browser.

I'm including the test results here, which I find confusing to interpret since I can't figure out why one fails and the other doesn't, considering that both resources use the HTTPS protocol.

--- STREMIO ----
MYUSER> version=$(curl -Ls https://api.github.com/repos/REVENGE977/stremio-enhanced/releases | sed 's/[()",{} ]/\n/g' | grep -oi "https.*mage$" | grep -vi "i386\|i686\|aarch64\|arm64\|armv7l" | head -1)
MYUSER> wget "$version"
--2026-01-07 10:17:35--  https://github.com/REVENGE977/stremio-enhanced/releases/download/v1.0.2/Stremio.Enhanced-1.0.2.AppImage
Conectando con 192.168.1.10:2020... conectado.
Petición Proxy enviada, esperando respuesta... 302 Found
Localización: https://release-assets.githubusercontent.com/github-production-release-asset/522049414/c00b051b-f2ae-4e6b-8c48-2fb6b6c28159?sp=r&sv=2018-11-09&sr=b&spr=https&se=2026-01-07T10%3A03%3A34Z&rscd=attachment%3B+filename%3DStremio.Enhanced-1.0.2.AppImage&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2026-01-07T09%3A02%3A39Z&ske=2026-01-07T10%3A03%3A34Z&sks=b&skv=2018-11-09&sig=Zd7Bvu6yrpmzCmeIpOeWy26kCnUSSUDhFFxTbc2oK78%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2Nzc4MTA1NiwibmJmIjoxNzY3Nzc3NDU2LCJwYXRoIjoicmVsZWFzZWFzc2V0cHJvZHVjdGlvbi5ibG9iLmNvcmUud2luZG93cy5uZXQifQ.MEaaNuDxOel1IN2VJEeJJy3mlbvhxgKLntxfK_4pVls&response-content-disposition=attachment%3B%20filename%3DStremio.Enhanced-1.0.2.AppImage&response-content-type=application%2Foctet-stream [siguiendo]
--2026-01-07 10:17:36--  https://release-assets.githubusercontent.com/github-production-release-asset/522049414/c00b051b-f2ae-4e6b-8c48-2fb6b6c28159?sp=r&sv=2018-11-09&sr=b&spr=https&se=2026-01-07T10%3A03%3A34Z&rscd=attachment%3B+filename%3DStremio.Enhanced-1.0.2.AppImage&rsct=application%2Foctet-stream&skoid=96c2d410-5711-43a1-aedd-ab1947aa7ab0&sktid=398a6654-997b-47e9-b12b-9515b896b4de&skt=2026-01-07T09%3A02%3A39Z&ske=2026-01-07T10%3A03%3A34Z&sks=b&skv=2018-11-09&sig=Zd7Bvu6yrpmzCmeIpOeWy26kCnUSSUDhFFxTbc2oK78%3D&jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmVsZWFzZS1hc3NldHMuZ2l0aHVidXNlcmNvbnRlbnQuY29tIiwia2V5Ijoia2V5MSIsImV4cCI6MTc2Nzc4MTA1NiwibmJmIjoxNzY3Nzc3NDU2LCJwYXRoIjoicmVsZWFzZWFzc2V0cHJvZHVjdGlvbi5ibG9iLmNvcmUud2luZG93cy5uZXQifQ.MEaaNuDxOel1IN2VJEeJJy3mlbvhxgKLntxfK_4pVls&response-content-disposition=attachment%3B%20filename%3DStremio.Enhanced-1.0.2.AppImage&response-content-type=application%2Foctet-stream
Conectando con 192.168.1.10:2020... conectado.
Petición Proxy enviada, esperando respuesta... 200 OK
Longitud: 122415413 (117M) [application/octet-stream]
Grabando a: «Stremio.Enhanced-1.0.2.AppImage.2»

Stremio.Enhanced-1.0.2.AppImage.2      100%[===========================================================================>] 116,74M  11,2MB/s    en 10s

2026-01-07 10:17:46 (11,2 MB/s) - «Stremio.Enhanced-1.0.2.AppImage.2» guardado [122415413/122415413]

MYUSER> curl -O "$version"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0   0     0   0     0     0     0  --:--:-- --:--:-- --:--:--     0

However, shutter encoder download fails, with wget and with curl

---- SHUTTER ENCODER -------------------

MYUSER> version="https://www.shutterencoder.com/Shutter%20Encoder%20$(curl -Ls "https://api.github.com/repos/paulpacifico/shutter-encoder/releases/latest" | sed 's/[()",{} ]/\n/g' | grep -oiE "tag/([0-9.]+)" | sed 's/tag\///')%20Linux%2064bits.AppImage"
MYUSER> wget "$version"
--2026-01-07 10:07:27--  https://www.shutterencoder.com/Shutter%20Encoder%2019.8%20Linux%2064bits.AppImage
Conectando con 192.168.1.10:2020... conectado.
Tunnel failed proxy: Proxy Authentication Required SSL connection can't be stablished.
MYUSER> curl -O "$version"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0   0     0   0     0     0     0  --:--:-- --:--:-- --:--:--     0
curl: (56) CONNECT tunnel failed, response 407

[ivan-hc]

Yes, it seems that the domain refuses calls from terminal. Have you tried with an user agent?

PS: my issue opened for shutter-encoder is still opened paulpacifico/shutter-encoder#355

[RafaelLinux]

It's a proxy domains whitlist, so changing UA name trick will not work :(

In fact, I tested it from a web browser without using a username and password, and it allowed me to download https://github.com/REVENGE977/stremio-enhanced/releases/download/v1.0.2/Stremio.Enhanced-1.0.2.AppImage without any problems.

If I try to do the same with https://www.shutterencoder.com/Shutter%20Encoder%2019.8%20Linux%2064bits.AppImage without entering a username and password, it's impossible to download the file.

[ivan-hc]

Anyway I think I have a similar issue in github actions, since I have to blacklist the following apps

https://github.com/ivan-hc/amcheck/blob/ad0953de1741c3fdd2fbd9b013e9c6e38f92b65d/.github/workflows/AMCHECK.yml#L344

I can install and test them from my PC, not in github actions.

"amcheck" is the repo where every hour 250 installation scripts are tested, so I know when a source is down or broken or no more unavailable... so I can remove them from this database.

But shutter-encoder works well there.

[Ma5t3rful]

@stoffel2 I use appman behind a local proxy as well. but I don't have any problems with appman.

running http_proxy='http://120.0.0.0' https_proxy='http://127.0.0.0' appman update gives me an error so this means that it really cares about the proxy settings. How do you set your proxy. You usually should export the env vars and put it into .bashrc and then call the program normally. for apt and pacman you can call sudo with -E flag and the proxy will go through the sudo and apt will use it.

Shameless plug: If you are using a local proxy and your debian is not too old, You can use ProxyMaster.

• Undo everything that you have done. (.wgetrc, etc)
• Just add a single line to your .bashrc and it will do the rest.

[ivan-hc]

Shameless plug: If you are using a local proxy and your debian is not too old, You can use ProxyMaster.

* Undo everything that you have done. (`.wgetrc`, etc)

* Just add a single line to your `.bashrc` and it will do the rest.

Just added ea999b0

[stoffel2]

Shameless plug: If you are using a local proxy and your debian is not too old, You can use ProxyMaster.

* Undo everything that you have done. (`.wgetrc`, etc)

* Just add a single line to your `.bashrc` and it will do the rest.

Just added ea999b0

Thanks, I'll look into that!

@Ma5t3rful: I wrote my script to set proxy for apt, env, and curl. I can add wget, but I only have a few VM that run behind a proxy, so it's not a major issue for me.

[ivan-hc]

This issue hasn't been addressed for a few months.

I have a solution, and it's the same one we use for sed, which is a command, but for AM it's also a function that allows you to switch between GNU sed and other non-GNU sed variants.

AM/APP-MANAGER

Lines 221 to 243 in 508586f

	# Force usage of a GNU implementation of "sed"
	sed() {
	if [ "$NO_SED_I" = true ] && [ "$1" = '-i' ]; then
	if command -v gsed >/dev/null 2>&1; then
	command gsed "$@"
	else
	shift
	tmpsedYYY="$(command sed "$@" 2>/dev/null)"
	while [ "$#" -gt 1 ]; do shift; done
	if [ -n "$tmpsedYYY" ] && [ -f "$1" ]; then
	echo "$tmpsedYYY" > "$1"
	unset tmpsedYYY
	else
	>&2 echo $"💀 ERROR: Your version of sed does not support '-i' flag without extension, we tried to workaround and failed" | _fit
	>&2 echo $" Please install gsed"
	unset tmpsedYYY
	return 1
	fi
	fi
	else
	command sed "$@"
	fi
	}

As a function, it applies to all modules and scripts used via AM.

In this sense, we could try alternating

curl -Ls "$@"

with

wget -q -O - "$@"

But I'm not sure. I haven't received any further updates on this problem, which doesn't seem to have recurred.

Any configuration files to edit/create? I don't know.

I asked for a way to identify "special" wget configurations on systems, and it wasn't given to me. I can't reproduce the problem, even though I'm a Debian user.

Since this issue has been stalled for quite some time, I'll convert it into a discussion thread. You'll have the opportunity to provide further solutions and perspectives there.

[RafaelLinux]

Were the tests you performed on Debian done with authentication enabled? Remember that the problem lies with the username/password prompt. It's not the only application that fails due to the proxy, but some allow you to specify the username and password via configuration or command-line parameters when the system requests them to access the proxy.