build own web-gui
Howdy I'm apology if this isn't correct list but I didn't found any way... I need build my own webgui to run bash scripts on my server: that scripts could be something like this (execute by root user): #!/bin/bash # pr.sh # /etc/postfix reload So, I must create a gui do "reload postfix service" (and using it from internet) I can write a php script like this: $output"; ?> But I'm afraid about security issue I've also ssl on apache web. What is the best way to create a "web security gui"? Use post/put apache commands? using php code? Thanks for help! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/b9224a65e75765f47fd24c36c89a6860.squir...@fuckaround.org
Bug#726918: ITP: pear-channels -- PEAR channels for various projects
Package: wnpp Severity: wishlist Owner: David Prévot Control: forcemerge -1 710788 714474 714813 * Package name: pear-channels Version : 0.0.1 Upstream Author : Debian PHP PEAR Maintainers * URL : http://anonscm.debian.org/gitweb/?p=pkg-php/pear-channels.git * License : BSD-3-Clause Programming Lang: Perl Description : PEAR channels for various projects This package provides the PEAR channel registry entries for various projects: * Apache log4php, oodt and zetacomponents * AWS * Doctrine * Guzzle * Horde * Michel Fortin * Phing * PHPUnit * Symfony (versions 1 and 2) . PEAR is a framework and distribution system for reusable PHP components. A PEAR channel is a website that provides package for download and a few extra meta-information for files. The project list will of course be extended following the needs: I just compiled the 4 existing pear-*-channel packages with the 3 other pear-*-channel packages currently sitting in NEW, and added a few more after looking at the current php* prospective packages in WNPP. Do not hesitate to point me to more channels, or even better, add them directly in the Git repository as soon as the structure exists. Regards David P.-S.: On Fri, Aug 9, 2013 at 6:10 AM, Joerg Jaspert wrote: > Hi Maintainer, > > seriously - what the [insert something here]? […] > Also, what does it do? It seems to "register a pear channel", whatever > that does, but a quick google tells me that this can be done by a "pear > -D auto_discover=1 install guzzlephp.org/pear/guzzle" or maybe "pear > channel-discover guzzlephp.org/pear" too. (I may be > wrong, I have nothing with php nor pear). The existing and awaiting pear-*-channel packages do the pear dance without relying on network access, in order to make them compatible with the Debian standards for building packages. Hopefully, this pear-channels package will also address ftpmaster’s concerns and avoid further “[insert something here]” kind of “discussion”. signature.asc Description: Digital signature
Re: Bug#726393: general: Possible malware infections in source packages
On 18 October 2013 12:41, Kevin Chadwick wrote: >> I have to join Marc here and say "me too". In my organisation we >> actually have those controls in place (antivirus/antimalware) in the >> Internet gateways and we do not disable them for specific traffic >> flows unless a detailed risk analysis has been done (and approved). > > Personally I disagree with this approach as you are making the gateways > themselves more open to attack adding risk to all rather than the > targetted, You can disagree with this approach. However, in my 10+ experience setting up security gateways for Internet traffic (mostly for HTTP/FTP/SMTP) I've seen only a few vulnerabilities in the gateways themselves. Many of the gateways I have deployed are either network appliances with a Common Criteria certification (see http://www.commoncriteriaportal.org/), or are deployed using specific software running in a hardened (again, Common Criteria certified) operating system configuration. So I'd say the risk of exposing "all" by running a properly setup gateway is rather low. In my organisation (and I know we are not alone here), we do not just rely on the antivirus running on the desktops. We also do rutinary anti-virus/anti-malware checks on gateways running in a DMZ and block suspicious files that cannot be analysed (e.g. encrypted files not using corporate encryption, such as a ZIP file with a password). It's not just us, it is a common approach followed by many organisations and is based on the "defence-in-depth" principle. > especially when antivirus are so easy to fool anyway. That's also why we analyse incoming files with more than one antivirus engine. And that's also why we do behavioral analysis (i.e. run downloaded software in a sanbox) to detect malicious files. > There are many perfectly legitimate hacking tools that may hit the repo > that AV will pickup (backtrack distro has many) but also is their any > danger of av browser plugins and google even blocking debian.org. If somebody in my organisation is downloading and running hacking tools, I (with my network/security admin hat on) want to know it. These tools are only allowed for a specific group of individuals and under specific conditions, and I expect our gateways to block these downloads too. Regards Javier -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cab9b7usbptbv4belvars_wketn_3uyd1g7hody+o4kazcox...@mail.gmail.com
Bug#726940: ITP: node-buffer-crc32 -- computes crc32 of buffers and strings - module for Node.js
Package: wnpp Severity: wishlist Owner: "Jérémy Lal" * Package name: node-buffer-crc32 Version : 0.2.1 Upstream Author : Brian J. Brennan * URL : https://github.com/brianloveswords/buffer-crc32 * License : Expat Programming Lang: JavaScript Description : computes crc32 of buffers and strings - module for Node.js This module provides a standard implementation of the error-detecting code known as 32-bit Cyclic Redundancy Check. . Node.js is an event-based server-side javascript engine. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131020200138.2047.77930.reportbug@imac.chaumes
