Toolbox: 개발 중인 코드의 버그 및 맬웨어로부터 보호하기 위한 격리된 개발 환경

/home이 없는 영구 사용자 컨테이너를 원하십니까? 요구 사항/사용 사례를 더 잘 이해하려고 노력합니다. - 그냥 표준 일회용 Fedora 컨테이너를 실행하는 것과 비교하면 어떻습니까?

가정과 직장 모두에 사용되는 Unix 계정을 고려하십시오. 작업 컨테이너의 경우 작업 디렉터리만 컨테이너에 탑재하는 것을 선호할 수 있습니다.

신뢰할 수 없는 GUI 앱을 고려하십시오. 파일을 로드/저장하려면 특정 폴더에만 액세스해야 할 수 있습니다. 내 .ssh 폴더 및 기타 관련 없는 파일에 액세스할 필요가 없습니다.

보안 강화를 위해 Chrome OS는 기본적으로 호스트에서 컨테이너로 폴더를 공유하지 않습니다. 홈 디렉토리 또는 USB 드라이브에서 컨테이너에 데이터를 제공하려는 경우 명시적으로 공유합니다.

기본적으로 신뢰할 수 없는 컨테이너에 모든 데이터를 제공하면 보안 기능으로서의 컨테이너화는 상당한 가치를 잃게 됩니다!

@juhp Haskell 패키지를 잘 다루는 것 같습니다. 원격으로 설치한 Haskell 패키지 중 하나가 손상되었다고 가정합니다. Haskell 패키지는 .ssh 폴더 또는 Bitcoin 지갑에 액세스해야 합니까? 기본적으로 모든 것을 Haskell 개발 환경에 공유하는 이유는 무엇입니까?

꽤 최근에 설치된 경우 Bitcoin을 로컬로 사용할 수 있는 NPM 모듈이 있었습니다.
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

이 모듈은 인기가 많았고 실제로 우리 팀에서 이를 우리 트리에 설치했습니다. 우리는 비트코인 ​​절도를 유발하는 다른 기준을 충족하지 않았지만, 우리의 개발 환경이 기본적으로 홈 디렉토리에 완전히 액세스할 수 없었다면 그 위험은 완전히 완화되었을 것입니다. 어떤 직원도 이 개발 환경에서 비트코인 ​​지갑을 공유하기로 선택하지 않았을 것입니다.

이것은 완전히 유효하지만 어려울 것입니다.

실질적으로 말해서, 가장 좋은 방법은 도구 상자를 별도의 사용자 로 쉽게 실행할 수 있도록 하는 것입니다(각각 고유한 /home 가 있는 새 uid를 일시적으로 생성) - 그렇게 하려면 권한 있는 시스템 서비스가 필요합니다.

이제 읽기 전용과 같은 일부 파일을 공유하려는 경우 더 복잡해집니다.

디렉토리 bind-mount에서 파일/디렉토리를 제외할 수 있습니까?

문제를 확실히 이해하기 위해 한 줄의 코드로 홈 디렉토리를 마운트하는 것을 볼 수

    --volume "$HOME":"$HOME":rslave

그러나 여기서 문제는 여전히 GUI 앱과 일부 다른 기능이 작동하도록 만드는 것입니다. 이러한 기능은 컨테이너 내부와 외부의 사용자가 동일할 것으로 예상하기 때문입니다.

이것은 실제로 상당히 중요한 기능입니다. 기본적으로 집에 마운트해도 괜찮다고 생각하지만, 컨테이너를 신뢰할 수 없는 방식으로 사용할 수 있어야 합니다. 컨테이너에 집을 장착하는 것은 컨테이너를 신뢰한다고 가정하지만 일회용 컨테이너에서는 그렇지 않은 경우가 많습니다. 일부 NPM 모듈을 테스트하는 것과 같은 간단한 경우에도 내 홈 폴더를 손상시키지 않을 것이라는 마음의 평화를 갖고 싶습니다.

@markstos 홈 마운트 없이 또는 특정 디렉토리(cwd)만 마운트하는 경우 수행할 수 있는 작업을 테스트할 수 있습니까?

@juhp 사실 이것은 나를 위한 쇼스토퍼였습니다. 이 누락된 기능에

Fedora가 다른 Linux 배포판에서 오는 사용자를 환영하려는 경우 컨테이너에서 이전 배포판을 쉽게 실행할 수 있도록 하는 것이 좋은 출발점이 될 것입니다.

@marktos 감사합니다 - 저는 또 다른 Toolbox 사용자입니다. :-)
더 많은 OS를 지원하도록 Toolbox를 확장하는 것이 실제로 매우 유용할 것이라는 데 전적으로 동의합니다.
Toolbox는 Silverblue 없이도 작동합니다(즉, 다른 Fedora 에디션에서).

@juhp 사실 이것은 나를 위한 쇼스토퍼였습니다. 이 누락된 기능에

당신은 전에 무엇을 했습니까? 사용 중이던 Silverblue에서 작동하지 않는 다른 도구/접근법이 있습니까?

예를 들어 일회용 VM(QubesOS와 같은)을 사용하거나 이 스레드의 제안 중 일부를 구현하는 사용자 지정 스크립트를 사용하는 것을 막는 것은 없습니다. 틀림없이, 우리는 좀 더 독단적이고 QubesOS와 유사한 기능을 Silverblue에 구축해야 합니다.

그러나 어쨌든 기존 VM 및 컨테이너 기술이 있습니다. 사실 toolbox 오늘은 호스트와 의도적으로 podman 를 흐리게 만드는 스크립트의 무리입니다. 통합을 원하지 않으면 podman run ...로 시작할 수 있습니다. 이것이 기본값이기 때문입니다.

나는 내 개인 노트북에 크롬 OS를 사용하기 시작하고있는 한 @cgwalters은 통해 VM에서 컨테이너 내에서 실행 내 개발 환경 (및 그 밖의 거의 모든)를 갖는 보안 감사 와서 베이컨의 프로젝트. GUI 앱과 명령줄 앱을 지원한다는 점이 마음에 듭니다. 또한 컨테이너가 기본적으로 비공개라는 점도 마음에 듭니다. 데이터 폴더나 USB 드라이브를 명시적으로 공유해야 합니다. 반면에 사운드 및 웨이랜드 지원은 해당 컨테이너에 자동으로 설정됩니다.
URL
대신 업무용 랩톱에서 사용할 유사한 솔루션을 평가하고 있습니다. 한 가지 옵션은 PC 하드웨어용 오픈 소스 Chrome OS인 Neverware의 Cloudready입니다. 때때로 Crostini가 충돌하는 포트가 있고 데이터가 손실되어 다시 시작해야 합니다. 그런 이유로 지금은 ChromeOS/Crostini를 ​​두 배로 줄이는 것을 주저합니다.

Silverblue는 기본적으로 Ubuntu 컨테이너를 지원하지 않는 것으로 보이며 내 개인 데이터를 내가 신뢰하지 않을 컨테이너와 과도하게 공유한다는 것을 발견할 때까지 매력적이었습니다. Clear Linux도 살펴보았습니다. 컨테이너에서 거의 모든 것을 실행한다는 동일한 개념을 가지고 있습니다. 나는 Intel과 x86과의 긴밀한 관계에 흥분하지 않습니다. 또한 주로 데스크탑 OS가 아닙니다. 마지막(기본값?) 옵션은 Ubuntu를 데스크탑으로 사용하고 더 많은 개발 작업을 Chrome의 Crostini가 사용하는 LXD 컨테이너로 옮기는 것입니다. 호스트 OS가 다르더라도 직장과 개인 랩톱 간에 LXD 컨테이너를 복사할 수 있어야 합니다. LXD 템플릿을 사용하여 Wayland 지원을 위해 컨테이너에 충분한 마운트를 공유하는 템플릿을 설정할 수 있어야 합니다.

참고: Rhythmbox를 유지해 주셔서 감사합니다!

아마도 toolbox 의 사명을 잘못 이해한 것 같습니다. README에서:

.. 이러한 시스템의 의도는 호스트에 소프트웨어를 설치하지 못하도록 하는 것입니다.

왜요? 기본적으로 모든 개인 데이터를 컨테이너에 공유하는 것이 기본이므로 향상된 보안을 요구할 수 없다고 생각합니다.

나머지 잠재적인 이점은 격리이므로 충돌하는 소프트웨어 버전을 나란히 설치할 수 있습니다.

항상 공유 동작이 유지되는 경우 toolbox 전체 홈 디렉토리를 컨테이너로 공유하고 동작을 비활성화할 수 없으며 신뢰할 수 없는 항목과 함께 사용해서는 안 된다는 문서를 업데이트하는 것이 도움이 될 수 있습니다. 컨테이너.

podman을 직접 사용할 수 있다는 것은 알지만 GUI 통합이 포함된 컨테이너 솔루션에 관심이 있었습니다. podman 로 이를 수행하는 방법을 검색할 때 toolbox 를 사용하는 것이 권장되는 접근 방식입니다.

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

@markstos 관심이

여기에 약간의 혼란이 있다고 생각합니다.

우리의 README.md 는 몇 달에 걸쳐 성장하고 변형되었으며 아마도 이해하기가 조금 더 어려울 것입니다. 이전에는 단순히 Hacking on OSTree 기반 Fedoras라고 했습니다 .

Silverblue(또는 해당 문제에 대한 다른 OSTree 기반 OS)를 설치하면 OS 디버깅 또는 개발 환경 설정의 어려움이 즉시 명백해집니다. Toolbox는 그 문제를 해결하기 위해 존재합니다.

.. 이러한 시스템의 의도는 호스트에 소프트웨어를 설치하지 못하도록 하는 것입니다.

왜요? 기본적으로 모든 개인 데이터를 기본적으로 컨테이너에 공유하는 것입니다.
향상된 보안을 주장할 수 있다고 생각하지 마십시오.

보안은 오버로드된 단어입니다. Toolbox는 이에 대해 어떠한 주장도 하지 않습니다.

수십 년 동안 UID로 실행되는 모든 프로세스는 개인 암호화 키, 문서, 사진 등을 살펴보고 사용자가 알지 못하는 사이에 지구 반대편까지 전송할 수 있었습니다. 이것이 자유 소프트웨어 클라이언트 OS의 현상입니다.

Flatpak은 각 그래픽 응용 프로그램과 운영 체제를 자체 보안 도메인으로 분리하여

그러나 상단에서 언급했듯이 이 잠긴 OS 이미지는 고유한 문제 집합을 나타냅니다. 이를 해결하는 방법은 편의성과 보안 간의 균형입니다. 솔루션이 급진적일수록 기존 Linux 사용자가 Silverblue를 채택하기가 더 어려워집니다.

현재 Toolbox는 보안보다 채택에 중점을 두고 있습니다. Toolbox를 사용하는지 여부에 관계없이 Silverblue는 자유 소프트웨어 클라이언트 OS의 상태를 크게 개선하고 이를 사용자의 손에 전달하는 것은 긍정적인 단계가 될 것이기 때문입니다.

또한 보안에 관한 것만이 아닙니다. 안정성에 관한 것이기도 합니다.

기존의 Linux 배포판을 테스트하는 것은 매우 어렵습니다. 패키지와 미러는 전 세계의 무작위 미러에 대한 무작위 기여자에 의해 항상 업데이트되고 있습니다. 조합 폭발은 정교한 동결 시스템에 의해서만 관리될 수 있습니다. 일이 잘못되면 사용자가 업데이트를 되돌리기가 매우 어렵고 업데이트 도중 정전과 같은 일이 시스템을 복구할 수 없을 정도로 손상시킬 수 있습니다.

OSTree 기반 OS는 모든 것을 바꿉니다.

podman을 직접 사용할 수 있다는 것을 알지만 GUI가 있는 컨테이너 솔루션에 관심이 있었습니다.
완성. podman으로 이를 수행하는 방법을 검색할 때 도구 상자를 사용하는 것은
권장되는 접근 방식:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

문제는 왜 Podman을 사용하여 그래픽 응용 프로그램을 실행하려는 것입니까? :)

일반적으로 Podman(또는 OCI 컨테이너)은 GUI 앱 실행에 좋지 않은 옵션입니다. 그것이 Flatpak이 존재하고 Toolbox가 그것과 경쟁하지 않는 이유입니다.

그러나 Toolbox 컨테이너에 데스크톱 통합이 있다는 점에서 중복이 있으며, Flatpaked가 아닌 GUI 앱을 실행하는 기능이 단기적으로 매우 유용한 경우가 있습니다. 원하는 응용 프로그램이 아직 Flatpaked되지 않았거나 Flatpaked 버전에 일부 기능이 누락되었을 수 있습니다. 그래픽 응용 프로그램에서 사용하는 일부 라이브러리에서 작업하고 있고 라이브러리가 예상대로 작동하는지 확인하기 위해 일회성 테스트 프로그램을 빠르게 실행하고 싶을 수 있습니다.

Toolbox는 실제로 이러한 경우에 도움이 될 수 있지만 Toolbox의 주요 목표가 그래픽 응용 프로그램을 컨테이너화하는 것이라고 말하는 것과는 다릅니다. Toolbox의 주요 목표는 OSTree 기반 OS에서 해킹을 수행할 수 있도록 하는 것입니다.

이제 Flatpak으로 제공되는 GNOME Builder 와 같은 컨테이너 네이티브 IDE를 사용하고 작업 중인 소프트웨어를 빌드하고 실행하기 위해 컨테이너를 자동으로 설정했다면 Toolbox가 전혀 필요하지 않을 것입니다.

그러나 모든 사람이 그놈 빌더를 사용하는 것은 아니며 Visual Studio Code와 같은 가장 인기 있는 IDE는 컨테이너 네이티브가 아닙니다. 따라서 도구 상자.

@debarshiray 사려 깊고 철저한 답변에 감사드립니다. 내가 위에 제시한 예는 Flatpak에서 다룰 수 있는 그래픽 앱에 대한 것이 아닙니다. Node.js 개발을 하는 예를 들었습니다. 최근 Node.js 종속성 체인에 로컬 암호화 지갑에서 훔칠 수 있는 실제 맬웨어가 있었습니다. SSH 키도 마찬가지로 쉽게 도난당할 수 있습니다. README에서는 프로젝트가 개발자를 대상으로 한다고 명시하고 있지만 기본적으로 컨테이너와 공유는 이러한 공격으로부터 개발자를 보호하지 않습니다.

Toolbox는 신뢰할 수 없는 종속성이 있는 CLI 개발을 수행할 때 개인 파일 도난으로부터 안전을 제공하지 않습니다. 최신 오픈 소스 소프트웨어의 복잡성을 감안할 때 종속성 트리에는 신뢰할 수 없는 부분이 있을 수 있습니다.

현재 README가 오해의 소지가 있음을 알았습니다. "컨테이너에서 완전히 권한이 없는" 실행은 보안처럼 들리지만 보안 극장일 뿐입니다. 모든 개인 파일은 컨테이너에서 액세스할 수 있습니다. 위에서 Toolbox는 보안에 대해 어떠한 주장도 하지 않을 것임을 분명히 했습니다. 컨테이너를 사용함에도 불구하고 보안이 아닌 편의를 위한 도구라는 점을 명확히 하기 위해 README에 포함시키는 것이 유용한 문장이라고 생각합니다.

@debarshiray 사려 깊고 철저한 답변에 감사드립니다. 내가 준 예
위의 내용은 Flatpak에서 다룰 수 있는 그래픽 앱이 아닙니다. 나는 주었다
Node.js 개발 예제. 최근 Node.js에 실제 악성코드가 있었습니다.
로컬 암호화 지갑에서 훔칠 수 있는 종속성 체인. SSH 키를 훔칠 수 있음
마찬가지로 쉽게. README에서는 프로젝트가 개발자를 대상으로 한다고 명시되어 있지만,
기본적으로 share-with-containers-by-default는 이러한 종류의 공격으로부터 개발자를 보호하지 않습니다.

예, 현재 Toolbox는 이미지 기반 OS 내에서 기존 패키지 기반 환경을 재현하려고 합니다.

현재 README가 오해의 소지가 있음을 발견했습니다. "컨테이너에서 완전히 권한이 없는 상태로 실행"
보안처럼 들리지만 보안 극장일 뿐입니다. 모든 개인 파일은 다음에서 액세스할 수 있습니다.
컨테이너. 위에서 Toolbox는 보안에 대해 어떠한 주장도 하지 않을 것임을 분명히 했습니다.
나는 그것이 README에 포함하여 그럼에도 불구하고
컨테이너 사용, 보안이 아닌 편의를 위한 도구입니다.

커밋 c047659c1d85ca982374da5c58ee7a24ba3847bd 는 해당 줄이 추가된 위치입니다. @cgwalters 는 도구 상자 컨테이너 내부의 고유한 UID에만 액세스할 수 있고 실제 루트(즉, 호스트의 UID 0)는 관련되지 않거나 사용할 수 없다고 말한 것으로 생각합니다.

나도 같은 문제가 있습니다. 나는 내 SSH 키와 기타 민감한 정보를 훔치는 것에 대해 걱정할 필요 없이 완전히 신뢰할 수 없는 소프트웨어를 실행할 수 있기를 바라는 마음으로 Silverblue를 설치했습니다.

도구 상자에서 이 작업을 수행할 수 없다는 사실은 큰 실망이었고 처음부터 Silverblue 사용을 재고하게 되었습니다. 개인적으로 나는 메인 OS 설치에 신경 쓰지 않는다. 나는 항상 그것을 다시 설치할 수 있습니다. 내가 진정으로 분리하고 싶은 정보는 내 홈 디렉토리에 있습니다.

홈 디렉토리의 어떤 부분이 공유되는지 더 세밀하게 지정할 수 있습니까? 도구 상자에 필요한 디렉터리(데스크톱 구성과 관련된 디렉터리 등)만 화이트리스트에 추가할 수 있다면 많은 문제가 해결될 것입니다.

이제 보안 문제에 대해 완벽하게 알고 있습니다. Qubes OS를 몇 년 동안 사용해 왔기 때문에 격리 문제는 어려운 문제입니다. 홈 디렉토리를 보호하더라도 컨테이너 내부에서 실행되는 프로그램은 클립보드와 같은 컨테이너 간의 다른 통신 수단을 항상 이용할 수 있기 때문에 충분하지 않습니다. 나는 이것을 알고 있으며 전체 Qubes 설치와 비교하여 도구 상자와 같은 편의를 대가로 이러한 위험 중 일부를 기꺼이 감수합니다.

해결 방법이 여기 에 게시되어

해결 방법은 사실 이용한다 toolbox 떠들썩한 파티 스크립트로 구현되어있는 참조 환경 변수 $HOME 의 경로 모든 경우에 /home/user 요구를 조회 할 수 있습니다. 그래서 환경 변수를 설정하여 $HOME 에 특정 통화에 toolbox 잠재적으로 신뢰할 수없는 용기와 공유 할 중요한 개인 파일의 전체 전체 홈 디렉토리 이외의 AA 디렉토리됩니다.

이를 기반으로 다음과 같은 래퍼로 도구 상자를 시작하여 도구 상자 구성만 포함하는 빈 디렉터리를 공유할 수 있는 것으로 보입니다.

#!/bin/bash
mkdir -p ~/toolboxes
HOME=~/toolboxes "$@"'

이 스크립트의 이름이 toolbox 이고 $PATH를 시스템 toolbox 앞에 넣으면 이 문제를 해결할 것으로 보입니다. 이 솔루션은 테스트되지 않았습니다.

이 기능은 이제 tlbx 포크에서 작동합니다: https://gitlab.com/uppercat/tlbx/issues/3

나도 같은 문제가 있습니다. 할 수 있기를 바라는 마음으로 Silverblue를 설치했습니다.
내 SSH를 훔치는 것에 대해 걱정할 필요 없이 완전히 신뢰할 수 없는 소프트웨어를 실행하십시오.
키 및 기타 민감한 정보.

음... 오해의 소지가 있는 것 같습니다. 신뢰할 수 없는 소프트웨어를 사용자로 실행하려는 경우 Flatpak은 이미 민감한 정보 손실에 대한 걱정을 줄여줍니다. 격리된 개발 환경을 원하신다면 그건 다릅니다.

또한, 이 중 어느 것도 Silverblue와 관련이 없습니다. 문제는 수십 년 동안 존재했으며 솔루션은 Silverblue에만 국한된 것이 아니라 기존 패키지 기반 OS에서도 작동합니다.

해결 방법은 toolbox 가 bash 스크립트로 구현된다는 사실을 이용합니다.
/home/user 의 경로가 있는 모든 경우에 환경 변수 $HOME 를 참조합니다.
조회할 필요가 있습니다. 따라서 특정 환경 변수 $HOME 를 설정하여
toolbox 호출하면 전체 홈 디렉토리가 아닌 다른 디렉토리가 귀중한 파일로 가득 차게 됩니다.
잠재적으로 신뢰할 수 없는 컨테이너와 공유할 개인 파일.

예, 깔끔한 해킹입니다. :)

그러나 Toolbox 프로젝트의 주요 목표는 패키지 기반 운영 체제에 필요한 노력과 거의 동일한 노력으로 이미지 기반(특히 OSTree 기반) 운영 체제에서 다양한 개발 환경을 설정할 수 있도록 하는 것입니다. 이러한 개발 환경을 보다 안전하게 만드는 것은 분명히 타당한 바램이지만 즉각적인 할 일 목록에 있는 것은 아닙니다. 문제는 새로운 것이 아니며 영원히 존재했기 때문입니다.

또한 Silverblue가 반드시 보안에 관한 것은 아닙니다. 나는 그것을 운영 체제의 안정성과 견고성의 개선으로 봅니다. 그러나 Flatpaks의 사용을 권장하므로 그런 의미에서 보안을 간접적으로 향상시킵니다.

따라서 패키지 기반 Linux 배포판에서 기존 문제의 일부를 유지하더라도 기능 패리티를 보장하는 데 가치가 있습니다. 일부 문제를 해결하고 기존 사용자 기반이 솔루션에 액세스할 수 있도록 하는 것이 아무 것도 해결하지 않는 것보다 낫습니다. :)

미해결 문제 목록이 통제 불능 상태가 되지 않고 현재 할 일 목록에 있는 항목을 대략적으로 반영하도록 이 문제를 닫을 것입니다. 그러나 향후 참조를 위해 계속 사용됩니다.

하지만 우리의 README.md 가 더 읽기 쉬워야 한다는 데 동의합니다.

흠, 나는 그 주장을 이해하지 못한다. 문제가 오래되고 영원히 존재하기 때문에 문제를 해결하지 않습니까?? 그것은 좋은 관점이 아닙니다, IMHO.
그리고 당신이 말했듯이 flatpak은 다음을 수행합니다. 단계적으로 보안을 향상하고 응용 프로그램을 격리합니다. 그들은 또한 "흠, 우리는 앱을 rpm 패키지로 영원히 출하했는데 왜 이 문제를 해결해야 합니까?"라고 말하지 않고 그냥 해결했습니다.

도구 상자가 홈 디렉토리도 분리하지 않아야 할 이유가 없습니다. 그래서 어쨌든 https://github.com/containers/toolbox/issues/348 에서 토론을 계속할 수 있다고 생각합니다.

툴박스의 기여자 및 유지 관리자는 이 스레드를 프로젝트에 투입된 아이디어와 작업에 대한 강타로 받아들이고 있다고 생각합니다. 그 아이디어에 흥분한 많은 사람들이 필요로 하는 기능으로 받아들여야 한다고 생각합니다. $HOME 이외의 작업 디렉토리를 마운트할 수 있는 기능에 대한 작업에 대한 저항이 없습니다. 기능과 사용 사례를 크게 개선하여 채택과 관심도를 높일 수 있는 기능입니다.

#348 에서 $HOME 변수 변경을 제안한 사람입니다. $HOME 디렉토리가 다른 두 개의 컨테이너로 작업하려고 할 때 문제가 발생하기 때문에 해키 솔루션입니다. 내 두려움은 도구 상자가 go로 다시 작성될 때 작동하지 않는다는 것입니다.

많은 사람들이 이 기능을 요구하고 있으며 많은 사람들이 도구 상자, rpm-ostree 및 silverblue를 채택하는 진입 장벽이 되었습니다. 보안에 관한 것이 아니더라도 도구 상자를 사용하여 작업할 수 있는 많은 가능성을 열어주는 기능입니다.

나는 내가 할 수만 있다면 이 문제를 도울 의향이 있으며 다른 사람들도 기꺼이 도울 것이라고 생각합니다. 이 기능이 논쟁의 여지가 없고 향후 도구 상자 릴리스에서 제외되기를 바랍니다. 제 생각에는 현재 그 안에 없는 유일한 것입니다. 마라톤에서 마지막 10미터를 끝내고 dnf를 얻는 것과 같습니다. (말장난 의도 :))

그것은 나를 위해 거래 차단기였습니다. 나는 도구 상자와 Silverblue를 포기한 후
이 결함을 찾는 것.

문제가 오래되고 영원히 존재하기 때문에
그냥 안풀어?? 그것은 좋은 관점이 아닙니다, IMHO.

즉각적인 할 일 목록 에 무언가가 없다는 것은 해결하지 않는 것과 같은 것이 우선순위 라는 것이 있습니다.

그리고 당신이 말했듯이 flatpak은 다음을 수행합니다. 단계적으로 보안을 개선하고
응용 프로그램을 격리합니다. 그들은 또한 "흠, 우리는 앱을 다음과 같이 배송했습니다.
rpm 패키지는 영원히, 왜 우리가 이 문제를 해결해야 합니까?", 그들은 방금 했습니다.
그것을 해결하십시오.

나는 당신이 그들이 라는 단어

좋아, 좋아, 그래서 내가 그것을 올바르게 해석한다면, 이것은 당신의 "즉시 해야 할 일 목록"에 없는 미래를 위한 아이디어일 수도 있습니다. (특히 포크에서 일부 패치를 선별 할 수 있다면 구현하기 쉬울 것이라고 생각합니다.)*

그렇다면 이 문제를 열어 두고 "도움이 필요함"으로 태그를 지정하십시오. 도움이 실제로 필요하지는 않지만... 이것을 구현하지 못하는 이유는 무엇입니까? 이 주제에 대한 PR을 수락한다고 말하면 구현될 것입니다.
나는 당신이 그것을 막지 못한다고 생각합니다. 그리고 당신은 여전히 ​​기능 패리티를 얻을 수 있습니다. :생각:

* 예, 이것이 Go에서 다시 작성된 것을 보고 압니다. 그러나 이것이 여전히 도움이 될 수도 있습니다. 적어도 구현하기 쉽다는 것을 보여줍니다.

참가자 중 누군가가 https://gitlab.com/bkhl/etui 에서 내 프로토타입에 대한 피드백을 확인하고 제공하려는 경우 이 문제를 약간 하이재킹합니다.

보다 엄격하게 포함된 개발 컨테이너를 원할 때 Toolbox의 대안으로 사용됩니다.

@bkhl 감사합니다! 북마크했습니다.