Package Details: skypeforlinux-stable-bin

Git Clone URL: (read-only, click to copy)
Package Base: skypeforlinux-stable-bin
Description: Skype for Linux - Stable/Release Version
Upstream URL:
Keywords: skype
Licenses: custom
Conflicts: skype, skypeforlinux, skypeforlinux-beta-bin, skypeforlinux-bin, skypeforlinux-preview-bin
Provides: skype, skypeforlinux
Submitter: bulletmark
Maintainer: bulletmark
Last Packager: bulletmark
Votes: 208
Popularity: 8.44
First Submitted: 2018-01-11 03:56
Last Updated: 2020-01-31 08:03

Pinned Comments

bulletmark commented on 2018-02-15 12:21

Please don't post here (or on any other AUR packages) about out of date versions. Use the "Flag package out-of-date" link at the top. Also, BEFORE flagging this package out of date please check that it has not already been updated here to the new version.

Note that AUR package skypeforlinux-stable-bin is the version Microsoft release as their "stable" version. AUR package skypeforlinux-preview-bin is the version Microsoft release as their preview version and is always a later version than the stable version. PLEASE DO NOT FLAG THE STABLE VERSION OUT OF DATE WITHOUT UNDERSTANDING THIS!

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 ... Next › Last »

tschertel commented on 2019-08-28 13:27

Sorry to ask, but why do we need "asar" for "make" the package if this is a "bin" package?

In Skype's website, there's no mention to any dependency but libappindicator1 or GtkStatusIcon. And they are just for notification icon.

bulletmark commented on 2019-08-21 00:10

@vasya, I added an install file with a warning.

vasya commented on 2019-08-20 10:57

@bulletmark I know very well that userns was enabled in linux and linux-lts some months ago. What I also know, is that linux-hardened does NOT have userns enabled. So for all people having this kernel (or a manually compiled kernel with this kind of flag), current skype won't work.

From that point of view, would an INSTALL script make sense, that warns the user if their kernel won't work with Skype? What do you think?

P.S. Thanks for making shellcheck-related fixes!

bulletmark commented on 2019-08-20 10:40

@vasya, yes, as I stated below and via the links I posted, that is the problem. But perhaps you did not read all those links, userns has been enabled on the Arch kernel since the middle of June 2019 (i.e. since 5.1.8) so this is not an issue for anyone running an up to date system.

vasya commented on 2019-08-20 07:02

@bulletmark the problem is that userns (user namespaces) is not enabled, and won't be enabled in forseeable future on linux-hardened, as well as it can be manually disabled by the user. The reason for that is that there were many CVE-s regarding it throughout history, and conceptually, userns exposes a lot of old code to a situation where it was never designed to run (assumed root, but only inside the namespace). I'm not a kernel developer though, so this is only what I've read, and personally, I follow with the conclusion.

For skype, this situation is problematic though. Nobody ever wants SUID for skype (except for Microsoft). While the chromium binary remains SUID, it can be "worked-around" with a symlink. But we can't make it the default because not all people have chromium installed, and there's no package saying "just give me chromium-s SUID, but not the whole browser".

To resolve the current situation. Maybe we should create an INSTALL script that queries userns state from the kernel, and if it is set to true, warns user about the situation and suggests a work-around for them?

h-pixako commented on 2019-08-20 06:11

@bulletmark Upgraded the kernel to 5.2.8 and it works. Thanks!

bulletmark commented on 2019-08-20 05:58

@h-pixako Look in your journal or perhaps run from the command line to see the error. Did you read the discussion below? You appear to be running an old kernel. You can try working around this with sudo sysctl kernel.unprivileged_userns_clone=1. This is the default since 5.1.8 (Arch is currently on 5.2.9) so should be fine on up to date systems.

h-pixako commented on 2019-08-20 05:48

Silently terminates after the last update: Remove setuid permission on chrome-sandbox.

Had to checkout the last working commit: 577cb2259ace

OS: 4.19.66-1-MANJARO x86_64 GNU/Linux

zeroxfourc commented on 2019-08-20 05:14

@bulletmark Oh okay, that's great. Thanks for doing your research :p

bulletmark commented on 2019-08-19 22:50

@vasya @zeroxfourc, See I will simply remove the setuid change it seems to me that anybody running a recent Arch kernel should not require it. Note work-around 1 commented here and see