Re: Bug#860067: ITP: minijail -- Utility to run a program inside a sandbox
On Tue, 11 Apr 2017 at 13:03:14 +1000, Andrew Pollock wrote: > There's potential functionality overlap with firejail ... and bubblewrap, which is probably a closer equivalent? (AIUI firejail does the equivalent of Flatpak's convenience layer around bubblewrap, and more, in the same setuid binary, which gives it a rather concerning attack surface.) S
Re: What's a safe way to have extensions in chromium in Debian?
On Tue, Apr 11, 2017 at 04:22:40AM +0200, Enrico Weigelt, metux IT consult wrote: > >> > >> > >> could anyone please give me some insight, was the security problems > >> are here exactly ? > > Extension auto-updating is considered "phoning home". > > Isn't there a way to just disable part ? Disabling extension auto-updating is wrong from several perspectives, including the security one. -- WBR, wRAR signature.asc Description: PGP signature
Bug#860084: ITP: libxdf -- static C++ library for loading XDF (multi-channel stream format) files
Package: wnpp Severity: wishlist Owner: Michael Hanke * Package name: libxdf Version : 0.93 Upstream Author : Yida Lin (?) * URL : https://github.com/Yida-Lin/libxdf * License : GPL3 Programming Lang: C++ Description : static C++ library for loading XDF (multi-channel stream format) files Libxdf is a cross-platform C++ library for loading multimodal, multi-rate signals stored in XDF files. Libxdf is a core component of bio-signal viewing application SigViewer. It can also be integrated into other C++ applications. The last release is just a few days old. This is a new dependency of the sigviewer package that needs an update to version 0.6 (#860083) This package will be maintained by the NeuroDebian team. At the moment upstream does not support building a shared library.
Yardi users contact list
Hi We would like to learn your interest in acquiring our recently *Yardi* users list which helps you to improve your business campaign. *Specialties*: real estate users, web-based solutions users, property management users, accounting software users, investment management users, cloud services users, multifamily users, commercial property management users, senior housing users, military housing users, public housing users, affordable housing users and more. You may also acquire the *Property Management/ Lease Administration Software* user’s company database such as: On-Site, Building Engines, AppFolio, Buildium, Propertyware, RealPage, Quicken Rental Property Management, CoStar Real Estate Manager, ARCHIBUS, CoStar COMPS, CoStar Lease Analysis, IBM TRIRIGA Facilities Manager….and many more. Please let me know your targeted criteria with geography to provide you with detailed information for your review. We specialize in providing Decision Maker’s contacts and Technology users list for all industries across the globe. Anticipate your response, Best Regards, Marisha Gerald Information Consultant Reply “remove” to Opt-Out.
AWS/Salesforce Users List
Hello, Would you be interested in acquiring *AWS **users,* *Salesforce users, **OpenStack users **and **Marketo** users *contact information for your sales and marketing campaigns? *The data fields we give include*: First/Last Name, Job Title, Company, Location, and Primary Industry, SIC Code, Number of Employees, Email Address, Income, and Web Address. Fill me in as to whether you are searching for contact data on whatever other innovation client bases or IT chiefs (C-, V-, D-, and M-level). Warm respects, *Evelyn Garrett* Request Generation To quit, please react with "Forget" in the title.
Re: What's a safe way to have extensions in chromium in Debian?
On 11.04.2017 10:22, Andrey Rahmatullin wrote: > On Tue, Apr 11, 2017 at 04:22:40AM +0200, Enrico Weigelt, metux IT consult > wrote: could anyone please give me some insight, was the security problems are here exactly ? >>> Extension auto-updating is considered "phoning home". >> >> Isn't there a way to just disable part ? > Disabling extension auto-updating is wrong from several perspectives, > including the security one. hmm, I'd actually feel better w/ manual update (on user request) for the unpackaged ones (the packaged ones of course go via apt). --mtx -- mit freundlichen Grüßen -- Enrico, Sohn von Wilfried, a.d.F. Weigelt, metux IT consulting +49-151-27565287
Bug#860116: RFH: cargo -- Rust package manager
Package: wnpp Severity: normal We request assistance with maintaining the cargo package, as well as Rust packaging in general. Firefox's next versions[1] will require rust, but the Debian pkg-rust team is severely short on time to maintain these packages. sylvestre@ and I are just about managing to keep rustc in Debian up-to-date in our spare time. lucab@ and gus@ know more about the rust ecosystem than either of us, but they have not been very active recently. lucab@ had been maintaining cargo. Right now, cargo needs to be updated to the next version, there are some open bugs about it: https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=cargo I have not yet looked at this package myself but if there are any questions you can probably prod lucab@ to answer them. He has a different handle on IRC, you can join #debian-rust on OFTC to talk to us. After this, we will need to update rustc to 1.16.0. This is packaged in git, and it works (doko@ has already uploaded it to Ubuntu) however it uses some deprecated Makefiles which are to be removed in the next 1.17.0 release. Therefore, we should try to upload 1.16.0 using the new "rustbuild" buildsystem which also build-depends on cargo. (To try this out, remove --disable-rustbuild from d/rules.) After that, we will have to figure out how to cross-compile cargo and rust for other architectures. So far, we have been bootstrapping rustc on other arches by using upstream's binary blobs, but this is not the ideal approach, and will become even harder once we have the rustc<->cargo cyclic build dependency. Upstream themselves prefer the cross-compilation approach, and had previously given me some tips that I need to go dig out again from my IRC logs. At some point we should also start packaging actual rust packages. Josh Triplett had been planning to automate a large part of this, the work is still incomplete but we have a Rust Packaging policy already: https://wiki.debian.org/Teams/RustPackaging/Policy Package automation tools: https://anonscm.debian.org/cgit/pkg-rust/dh-cargo.git (low-level dh glue) https://crates.io/crates/debcargo (high-level automater) [1] https://buildd.debian.org/status/package.php?p=firefox&suite=experimental
Bug#860118: ITP: node-json-loader -- json loader for webpack
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-json-loader Version : 0.5.4 Upstream Author : Tobias Koppers @sokra * URL : https://github.com/webpack/json-loader#readme * License : Expat Programming Lang: JavaScript Description : json loader for webpack json loader module for webpack . This library is a dependency for webpack. Webpack takes code targeted at node.js and makes it run in the browser. Node.js comes with API of its own that is not available in the browsers. Webpack exposes this code to programs that are unaware they are running in a browser . Node.js is an event-based server-side JavaScript engine. signature.asc Description: OpenPGP digital signature
Bug#860121: ITP: node-json-loader -- runs (webpack) loaders
Package: wnpp Severity: wishlist Owner: Pirate Praveen X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-loader-runner Version : 2.3.0 Upstream Author : Tobias Koppers @sokra * URL : https://github.com/webpack/loader-runner#readme * License : Expat Programming Lang: JavaScript Description : Runs (webpack) loaders This library is a dependency for webpack. Webpack takes code targeted at node.js and makes it run in the browser. Node.js comes with API of its own that is not available in the browsers. Webpack exposes this code to programs that are unaware they are running in a browser . Node.js is an event-based server-side JavaScript engine. signature.asc Description: OpenPGP digital signature
Re: Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
Sent from my MetroPCS 4G LTE Android device
init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]
On 17.02.2015 18:49, The Wanderer wrote: Hi folks, just digging out an older thread that was still laying around in my inbox - w/ about 2yrs distance, I hope it was enough cool down time so we discuss it more objectively about that. > libsystemd0 is not a startup method, or an init system. It's a shared > library which permits detection of whether systemd (and the > functionality which it provides) is present. >From a sw architects pov, I've got a fundamental problem w/ that appraoch: we'll have lots of sw that somehow has 'magically' additional functionality if some other sw (in that case systemd) happens to run. The official description is: "The libsystemd0 library provides interfaces to various systemd components." But what does that mean ? Well, more or less a catchall for anything that somehow wants to communicate w/ systemd. What this is actually for, isn't clear at all at that point - you'll have to read the code yourself to find out. And new functionality can be added anytime, and sooner or later some application will start using it. So, at least anybody who maintains and systemd-free environment (eg. platforms that dont even have it) needs run behind them and keep up. Certainly, systemd has a lot of fancy features that many people like, but also many people dislike (even for exactly the same reaons). The current approach adds a lot of extra load on the community and causes unnecessary conflicts. So, why don't we just ask, what kind of functionality do applications really want (and what's the actual goal behind), and then define open interfaces, that can be easily implemented anywhere ? After looking at several applications, the most interesting part seems to be service status reporting. Certainly an interesting issue that deserves some standardization (across all unixoid OS'es). There're lots of ways to do that under the hood - even without having to talk to some central daemon (eg. extending the classical pidfile approach to statfiles, etc). All we need yet is an init-system/service-monitor agnostic API, that can be easily implemented w/o extra hassle. A simple reference implementation probably would just write some statfiles and/or log to syslog, others could talk to some specific service monitor. Having such an API (in its own library), we'd already have most of the problems here out of the way. Each init system / service monitor setup comes with some implementation of that API, and applications just depend on the corresponding package - everything else can be easily handled by the existing package management infrastructure. No need for recompiles (perhaps even no need to opt out in all the individual packages). The same can be done for all the other features currently used from libsystemd, step by step. Maintenance of these APIs (specification and reference implementation) should be settled in an open community (perhaps similar to freedesktop.org for the DE's), not in an individual init system / service monitor project. I really wonder why people spent so much time in init system wars, instead of thinking clearly of the actual root problem to solve. --mtx
