Result:
found more than 674 distributions - search limited to the first 2001 files matching your query
( run in 2.023 )
App-Cme
view release on metacpan or search on metacpan
This file contains message digests of all files listed in MANIFEST,
signed via the Module::Signature module, version 0.96.
To verify the content in this distribution, first make sure you have
Module::Signature installed, then type:
% cpansign -v
It will check each file's integrity, as well as the signature's
App-Context
view release on metacpan or search on metacpan
lib/App/installguide/hosted.pod view on Meta::CPAN
'keep_source_where' => q[/home/username/.cpan/sources],
'makepl_arg' => q[PREFIX=/home/username],
'make_install_arg' => q[],
'mbuildpl_arg' => q[install_base=/home/username],
Then fire up the CPAN shell and install something. Then verify that it installed.
# perl -MCPAN -e shell
cpan> install App::Options
cpan> exit
# find ~/lib -name Options.pm -print
App-CriticDB
view release on metacpan or search on metacpan
lib/App/CriticDB.pm view on Meta::CPAN
Violations are stored together with the current I<mtime> for each file. On subsequent scans, files will be skipped unless their on-disk I<mtime> exceeds the previous value.
=head2 File deletions
The collector will re-verify the existence of all files at the beginning of each run. Files that no longer exist are removed from the datastore.
=head1 TODO
=head2 Collection
App-DHCPClientUtils
view release on metacpan or search on metacpan
scripts/multi-homed-routing.pl view on Meta::CPAN
[% END %]
[% END %]
# Helper functions
function verify_ip() {
local IP
local device=\\\$1
local IP_in=\\\$2
IP=\\\$(\\\$IP_TOOL -4 -o addr show dev \\\$device 2> /dev/null)
scripts/multi-homed-routing.pl view on Meta::CPAN
fail_cnt=0
[% FOREACH if IN interfaces %]
# Check interface [% if.device %]
verify_ip \\\$IF[% if.table %]_DEVICE \\\$IF[% if.table %]_IP
if [ \\\$? -eq 0 ]; then
# Add table [% if.table %] for interface [% if.device %]
\\\$IP_TOOL route flush table [% if.table %]
App-DWG-Sort
view release on metacpan or search on metacpan
This file contains message digests of all files listed in MANIFEST,
signed via the Module::Signature module, version 0.87.
To verify the content in this distribution, first make sure you have
Module::Signature installed, then type:
% cpansign -v
It will check each file's integrity, as well as the signature's
App-Daemon
view release on metacpan or search on metacpan
...
=item stop
will find the daemon's PID in the pidfile and send it a SIGTERM signal. It
will verify $App::Daemon::kill_retries times if the process is still alive,
with 1-second sleeps in between.
To have App::Daemon send a different signal than SIGTERM (e.g., SIGINT), set
use POSIX;
App-Deps-Verify
view release on metacpan or search on metacpan
lib/App/Deps/Verify.pm view on Meta::CPAN
my ( $self, $args ) = @_;
return [ map { LoadFile($_) } @{ $args->{filenames} } ];
}
sub verify_deps_in_yamls
{
my ( $self, $args ) = @_;
return $self->find_deps(
{
lib/App/Deps/Verify.pm view on Meta::CPAN
=encoding UTF-8
=head1 NAME
App::Deps::Verify - app and API to verify the presence of dependencies (Perl 5 modules, python3 modules, executables, etc.)
=head1 VERSION
version 0.12.2
=head1 SYNOPSIS
use App::Deps::Verify ();
App::Deps::Verify->new->verify_deps_in_yamls(
+{ filenames => [ $opt->{input}, ] } );
path( $opt->{output} )->spew_utf8("Success!");
Command-line usage:
lib/App/Deps/Verify.pm view on Meta::CPAN
help: display a command's help screen
plinst: install perl5 dependencies from CPAN
plupdatetask: update a Task::Weaver perl5 dependencies Task
py3list: list python3 dependencies from PyPI
verify: verify the presence of dependencies
=head1 DESCRIPTION
Here are some examples for YAML input files:
lib/App/Deps/Verify.pm view on Meta::CPAN
=back
=head1 METHODS
=head2 $obj->verify_deps_in_yamls({filenames => [@FILENAMES]})
Verify the presence of deps in all the YAML files.
=head2 $obj->find_deps({inputs => [\%hash1, \%hash2, ...]})
lib/App/Deps/Verify.pm view on Meta::CPAN
=back
=head2 Bugs / Feature Requests
Please report any bugs or feature requests by email to C<bug-app-deps-verify at rt.cpan.org>, or through
the web interface at L<https://rt.cpan.org/Public/Bug/Report.html?Queue=App-Deps-Verify>. You will be automatically notified of any
progress on the request by the system.
=head2 Source Code
lib/App/Deps/Verify.pm view on Meta::CPAN
Shlomi Fish <shlomif@cpan.org>
=head1 BUGS
Please report any bugs or feature requests on the bugtracker website
L<https://github.com/shlomif/app-deps-verify/issues>
When submitting a bug or request, please include a test-file or a
patch to an existing test-file that illustrates the bug or desired
feature.
App-Dest
view release on metacpan or search on metacpan
lib/App/Dest.pm view on Meta::CPAN
$ext = '.' . $ext if ( defined $ext );
$ext //= '';
try {
mkpath($path);
for ( qw( deploy verify revert ) ) {
open( my $file, '>', "$path/$_$ext" ) or die;
print $file "\n";
}
}
catch ($e) {
lib/App/Dest.pm view on Meta::CPAN
}
sub expand {
my ( $self, $path ) = @_;
print join( ' ', map { <"$path/$_*"> } qw( deploy verify revert ) ), "\n";
return 0;
}
sub list {
lib/App/Dest.pm view on Meta::CPAN
$self->revert($action);
return $self->deploy($action);
}
sub verify {
my $self = _new(shift);
my ($action) = @_;
return $self->_execute_action( $self->_build_execute_stack( $action, 'verify' )->[0] );
}
sub revert {
my $self = _new(shift);
my ( $dry_run, $action ) = _dry_check(@_);
lib/App/Dest.pm view on Meta::CPAN
deployed => 0,
},
);
}
elsif ( $a and $b ) {
( my $action = $b ) =~ s,/(?:deploy|verify|revert)(?:\.[^\/]+)?$,,;
push(
@{ $data->{actions} },
{
action => $action,
modified => 1,
lib/App/Dest.pm view on Meta::CPAN
wrap => $wraps->{$action},
},
);
if ( $type eq 'deploy' ) {
my $verify_file = ( <"$action/verify*"> )[0];
die "Action file does not exist for: verify $action\n" unless ($verify_file);
splice(
@execute_stack,
1,
0,
{
type => 'verify',
action => $action,
file => $verify_file,
wrap => $wraps->{$action},
},
);
}
};
lib/App/Dest.pm view on Meta::CPAN
$add->() unless ( $state->{$action}{deployed} and not $redeploy );
}
elsif ( $type eq 'revert' ) {
$add->() if ( $state->{$action}{deployed} or $state->{$action}{modified} );
}
elsif ( $type eq 'verify' ) {
$add->();
}
}
return \@execute_stack;
lib/App/Dest.pm view on Meta::CPAN
warn "Warnings from executed $file: $err_str\n";
}
}
};
if ( $type eq 'verify' ) {
$run->();
chomp($out);
die "$err\n" if ($err);
if ($out) {
print "ok - verify: $action\n";
}
else {
die "not ok - verify: $action\n";
}
}
else {
print "begin - $type: $action\n";
$run->();
print "ok - $type: $action\n";
}
my $dest_copy = $self->_rel2dir( '.dest/' . $self->_rel2root($action) );
rmtree($dest_copy) unless ( $type eq 'verify' );
dircopy( $action, $dest_copy ) if ( $type eq 'deploy' );
return 0;
}
lib/App/Dest.pm view on Meta::CPAN
dest clean [NAME] # reset dest state to match current files/dirs
dest preinstall [NAME] # set dest state so an update will deploy everything
dest nuke # de-initialize dest; remove all dest stuff
dest deploy NAME [-d] # deployment of a specific action
dest verify [NAME] # verification of tracked actions or specific action
dest revert NAME [-d] # revertion of a specific action
dest redeploy NAME [-d] # deployment of a specific action
dest revdeploy NAME # revert and deployment of a specific action
dest update [INCS] [-d] # automaticall deploy or revert to cause currency
lib/App/Dest.pm view on Meta::CPAN
=head1 DESCRIPTION
C<dest> is a simple "deployment state" change management tool. Inspired by
what Sqitch does for databases, it provides a simple mechanism for writing
deploy, verify, and revert parts of a change action. The typical use of
C<dest> is in a development context because it allows for simplified state
changes when switching between branches (as an example).
Let's say you're working with a group of other software engineers on a
particular software project using your favorite revision control system.
lib/App/Dest.pm view on Meta::CPAN
installation of libraries or other applications. Then let's also say the team
branches, works on stuff, shares those branches, reverts, merges, etc. And also
from time to time you want to go back in time a bit so you can reproduce a bug.
Maintaining the database state and the state of the system across all that
activity can be problematic. C<dest> tries to solve this in a very simple way,
letting you be able to deploy, revert, and verify to any point in time in
the development history.
See below for an example scenario that may help illustrate using C<dest> in a
pseudo real world situation.
lib/App/Dest.pm view on Meta::CPAN
=head2 add DIR
Once a project has been initialized, you need to tell C<dest> what directories
you want to "track". Into these tracked directories you'll place subdirectories
with recognizable names, and into each subdirectory a set of 3 files: deploy,
revert, and verify.
For example, let's say you have a database. So you create C<db> in your
project's root directory. Then call C<dest add db> from your root directory.
Inside C<db>, you might create the directory C<db/schema>. And under that
directory, add the files: deploy, revert, and verify.
The deploy file contains the instructions to create the database schema. The
revert file contains the instructions to revert what the deploy file did. And
the verify file let's you verify the deploy file worked.
=head2 rm DIR
This removes a directory from the C<dest> tracking list.
lib/App/Dest.pm view on Meta::CPAN
contents of the currently watched directories.
=head2 make NAME [EXT]
This is a helper command. Given a directory you've already added, it will create
the subdirectory and deploy, revert, and verify files.
# given db, creates db/schema and the 3 files
dest make db/schema
As a nice helper bit, C<make> will list the relative paths of the 3 new files.
lib/App/Dest.pm view on Meta::CPAN
vi `dest make db/schema sql`
# this will create and open in vi:
# db/schema/deploy.sql
# db/schema/revert.sql
# db/schema/verify.sql
And optionally, you can include any date/time format supported by L<POSIX>
C<strftime>.
dest make db/%s_action sql
lib/App/Dest.pm view on Meta::CPAN
want to:
dest deploy db/new_function
Note that you shouldn't add "/deploy" to the end of that. Also note that a
C<deploy> call will automatically call C<verify> when complete.
Adding a "-d" flag to the command will cause a "dry run" to run, which will
not perform any actions but will instead report what actions would happen.
=head2 verify [NAME]
This will run the verify step on any given action, or if no action name is
provided, all actions under directories that are tracked.
Unlike deploy and revert files, which can run the user through all sorts of
user input/output, verify files must return some value that is either true
or false. C<dest> will assume that if it sees a true value, verification is
confirmed. If it receives a false value, verification is assumed to have failed.
=head2 revert NAME [-d]
lib/App/Dest.pm view on Meta::CPAN
the code, they will be reverted.
If there are actions that are in the code that have been deployed, but the
"deploy" file has changed, then C<update> will revert the previously deployed
"deploy" file then deploy the new "deploy" file. (And note that the deployment
will automatically call C<verify>.)
You can optionally add one or more "INCS" strings to the update command to
restrict the update to only perform operations that include one of the "INCS" in
its action file. So for example, let's say you have a "db/changes" directory
with some actions and a "etc/changes" directory with some actions. If you were
lib/App/Dest.pm view on Meta::CPAN
example/
ls/
deploy
revert
verify
Let's then also say that the C<example/ls/deploy> file contains: C<ls>
I could create a deployment file C<example/dest.wrap> that looked like this:
lib/App/Dest.pm view on Meta::CPAN
point in time prior to the revert file existing, C<dest> maintains a copy of the
original revert file so it can revert the action. However, it will always rely
on whatever wrapper is in the current working directory.
The C<dest.wrap> is called with two parameters: first, the name of the change
program, and second, the action type ("deploy", "revert", "verify").
=head1 WATCH FILE
Optionally, you can elect to use a watch file that can be committed to your
favorite revision control system. In the root directory of your project, create
lib/App/Dest.pm view on Meta::CPAN
dest status # show the current status (which is everything is OK)
=head2 Create Schema Action
The next step would probably be to create your database schema as a C<dest>
action. Actions include deploy, verify, and revert files. You can use the "make"
command to create these files for you. The command will return the list of files
created, so you can wrap the command to your favorite editor.
dest make db/schema sql # create "schema" action as ".sql" files
vi `dest list db/schema` # list the "schema" files into vi
vi `dest make db/schema sql` # the previous 2 commands as 1 command
Your deploy file will be the SQL required to create your schema. The revert file
reverts what the deploy file deploys. The verify file needs to return some
positive value if and only if the deploy action worked.
Since your local CLI shell probably doesn't know how to execute SQL files
natively, you'll likely need to create a C<dest.wrap> file.
touch db/dest.wrap && chmod u+x db/dest.wrap && vi db/dest.wrap
This file if it exists will get executed instead of the deploy, verify, and
revert files, and it will be passed the action file being executed.
=head2 Status and Deploying
Now, check the project's C<dest> status:
App-Devbot
view release on metacpan or search on metacpan
This file contains message digests of all files listed in MANIFEST,
signed via the Module::Signature module, version 0.73.
To verify the content in this distribution, first make sure you have
Module::Signature installed, then type:
% cpansign -v
It will check each file's integrity, as well as the signature's
App-DistSync
view release on metacpan or search on metacpan
lib/App/DistSync.pm view on Meta::CPAN
$ua->timeout($to) if $to;
$ua->agent(sprintf("%s/%s", __PACKAGE__, $VERSION));
$ua->env_proxy;
$ua->proxy(['http', 'https'] => $props{proxy}) if $props{proxy};
$ua->ssl_opts(
verify_hostname => 0,
SSL_verify_mode => 0x00
) if $props{insecure};
return $self;
}
sub verbose { !!shift->{verbose} }
App-DocKnot
view release on metacpan or search on metacpan
t/data/generate/control-archive/docknot.yaml view on Meta::CPAN
* All of the configuration used to generate a `control.ctl` file for INN
and the `PGPKEYS` and `README.html` files distributed with pgpcontrol,
along with the script to generate those files.
* Software to process control messages, verify them against that
authorization information, and maintain a control message archive and
list of active newsgroups. Software is also included to generate
reports of recent changes to the list of active newsgroups.
* The documentation files included in the control message archive and
App-Dochazka-CLI
view release on metacpan or search on metacpan
0.042 2014-10-29 16:40 CET
- Parser.pm: support "/activity/code/:code"
0.043 2014-10-29 22:53 CET
- Parser.pm: support POST on 'activity/aid/:aid' and 'activity/code/:code',
even if just to verify 405 result
0.044 2014-10-30 18:20 CET
- Parser.pm: support 'activity/aid' and 'activity/code' resources
0.045 2014-10-31 21:20 CET
App-Dochazka-Common
view release on metacpan or search on metacpan
t/model/reset.t view on Meta::CPAN
my $testobj = $full_class->spawn( %{ $props_dispatch{$cl} } );
note( 'reset it' );
$testobj->reset;
note( 'verify that we have all the properties right' );
foreach my $prop ( @{ $full_class->attrs } ) {
note( "Property $prop" );
ok( exists( $props_dispatch{$cl}->{$prop} ) );
}
my %attrs;
map { $attrs{$_} = ''; } @{ $full_class->attrs };
foreach my $prop ( keys( %{ $props_dispatch{$cl} } ) ) {
ok( exists( $attrs{$prop} ) );
}
note( 'verify that all properties have been set to undef' );
foreach my $prop ( @{ $full_class->attrs } ) {
is( $testobj->{$prop}, undef );
}
}
App-Dochazka-REST
view release on metacpan or search on metacpan
lib/App/Dochazka/REST/Docs/Resources.pm view on Meta::CPAN
Allowed methods: POST
Given a set of intervals, all of which must fall within a single contiguous
168-hour (7-day) period, this resource performs all actions necessary to either
create a new schedule from those intervals or verify that an equivalent
schedule already exists.
Sample JSON:
{ "schedule" : [
App-Docker-Client
view release on metacpan or search on metacpan
lib/App/Docker/Client.pm view on Meta::CPAN
want_body_handle => 1,
(
$self->ssl_opts
? (
tls_ctx => {
verify => 1,
verify_peername => "https",
ca_file => $self->{ssl_opts}->{SSL_ca_file},
cert_file => $self->{ssl_opts}->{SSL_cert_file},
key_file => $self->{ssl_opts}->{SSL_key_file},
}
)
App-Dothe
view release on metacpan or search on metacpan
This file contains message digests of all files listed in MANIFEST,
signed via the Module::Signature module, version 0.79.
To verify the content in this distribution, first make sure you have
Module::Signature installed, then type:
% cpansign -v
It will check each file's integrity, as well as the signature's
App-DrivePlayer
view release on metacpan or search on metacpan
lib/App/DrivePlayer/SheetDB.pm view on Meta::CPAN
sub _open {
my ($self) = @_;
die "No spreadsheet_id configured\n" unless $self->spreadsheet_id;
# Use Drive API to verify the file exists and is not trashed before
# opening via Sheets API (which happily operates on trashed files).
my $drive = Google::RestApi::DriveApi3->new(api => $self->api);
my $meta = eval { $drive->file(id => $self->spreadsheet_id)->get(fields => 'id,trashed') };
if ($@) {
die "SHEET_NOT_FOUND: $@" if $@ =~ /404|not.?found/i;
App-Du-Analyze
view release on metacpan or search on metacpan
t/data/fc-solve-git-du-output.txt view on Meta::CPAN
8 ./fc-solve/site/wml/lib/jquery
316 ./fc-solve/site/wml/lib
8 ./fc-solve/site/wml/src/js-fc-solve/automated-tests
16 ./fc-solve/site/wml/src/js-fc-solve/text
36 ./fc-solve/site/wml/src/js-fc-solve
8 ./fc-solve/site/wml/src/verify-code
440 ./fc-solve/site/wml/src/downloads/dbm-fc-solver
444 ./fc-solve/site/wml/src/downloads
20 ./fc-solve/site/wml/src/pysol
4 ./fc-solve/site/wml/src/docs/distro
44 ./fc-solve/site/wml/src/docs
t/data/fc-solve-git-du-output.txt view on Meta::CPAN
42364 ./fc-solve/presets/soft-threads
308 ./fc-solve/presets/flares-based-scans-data
44208 ./fc-solve/presets
8 ./fc-solve/scripts/old
12 ./fc-solve/scripts/range-solving-of-deals
28 ./fc-solve/scripts/parallel-solve-and-verify-for-bakers-game
8 ./fc-solve/scripts/automatic-build-for-982-2fc-solving/kaz_tree
16 ./fc-solve/scripts/automatic-build-for-982-2fc-solving
172 ./fc-solve/scripts
36 ./fc-solve/rejects/Cmd-Line-Presets/Shlomif/FCS/CalcMetaScan
60 ./fc-solve/rejects/Cmd-Line-Presets/Shlomif/FCS
App-DubiousHTTP
view release on metacpan or search on metacpan
bin/dubious_http.pl view on Meta::CPAN
Setting up your own payload:
The default payload for evasion tests is the EICAR test virus which gets served
as ZIP file eicar.zip and if this gets not detected as plain TXT file eicar.txt.
To verify that the firewall does not block innocent files novirus.txt is used.
All of these payloads are builtin.
It is possible to setup own payload as following:
1. Reserve a directory for the payload files.
App-DuckPAN
view release on metacpan or search on metacpan
lib/App/DuckPAN/Web.pm view on Meta::CPAN
is => 'ro',
default => sub {
LWP::UserAgent->new(
agent => "Mozilla/5.0", #User Agent required for some API's (eg. Vimeo, IsItUp)
timeout => 5,
ssl_opts => { verify_hostname => 0 },
env_proxy => 1,
);
},
);
App-EC2Cssh
view release on metacpan or search on metacpan
lib/App/EC2Cssh.pm view on Meta::CPAN
}
sub _build_ec2{
my ($self) = @_;
# Hack so we never verify Amazon's host. Whilst still keeping HTTPS
IO::Socket::SSL::set_defaults( SSL_verify_callback => sub{ return 1; } );
my $ec2 = Net::Amazon::EC2->new({ %{ $self->config()->{ec2_config} || die "No ec2_config in config\n" } , ssl => 1 } );
return $ec2;
}
sub main{
App-Eduard
view release on metacpan or search on metacpan
lib/App/Eduard.pm view on Meta::CPAN
$msg = find_pgp_part $msg, $gpg
}
if ($gpg->is_signed($msg)) {
debug 'This mail looks signed';
my ($code, $keyid, $email) = $gpg->verify($msg);
return sign_error => (
message => stringify $gpg->{last_message}) if $code;
return sign => (
keyid => $keyid,
email => $email,
lib/App/Eduard.pm view on Meta::CPAN
} elsif ($status eq 'encrypt_error') {
say 'This message is encrypted but I was unable to decrypt it. GnuPG output: ', $params{message};
} elsif ($status eq 'sign') {
say 'This message is signed with key ', $params{keyid}, ' from ', $params{email};
} elsif ($status eq 'sign_error') {
say 'This message is signed but I was unable to verify the signature. GnuPG output: ', $params{message};
} elsif ($status eq 'plain') {
say 'This message is neither signed nor encrypted';
} elsif ($status eq 'error') {
say 'There was an error processing the message: ', $params{message};
}
App-ElasticSearch-Utilities
view release on metacpan or search on metacpan
lib/App/ElasticSearch/Utilities.pm view on Meta::CPAN
$opts{SSL_cert_file} = $DEF{CERT} if $DEF{CERT};
$opts{SSL_key_file} = $DEF{KEY} if $DEF{KEY};
# Disable Certificate Verification
if ( $DEF{INSECURE} ) {
$opts{verify_hostname} = 0;
$opts{SSL_verify_mode} = 0x00;
}
return \%opts;
}
sub _get_es_version {
lib/App/ElasticSearch/Utilities.pm view on Meta::CPAN
--host ElasticSearch host to connect to
--port HTTP port for your cluster
--proto Defaults to 'http', can also be 'https'
--http-username HTTP Basic Auth username
--password-exec Script to run to get the users password
--insecure Don't verify TLS certificates
--cacert Specify the TLS CA file
--capath Specify the directory with TLS CAs
--cert Specify the path to the client certificate
--key Specify the path to the client private key file
--noop Any operations other than GET are disabled, can be negated with --no-noop
lib/App/ElasticSearch/Utilities.pm view on Meta::CPAN
By default, HTTP proxy environment variables are stripped. Use this option to keep your proxy environment variables
in tact.
=item B<insecure>
Don't verify TLS certificates
=item B<cacert>
Specify a file with the TLS CA certificates.
App-Env-Login
view release on metacpan or search on metacpan
inc/Module/Install/CPANfile.pm view on Meta::CPAN
if ($self->is_admin) {
$self->admin->include_one_dist("Module::CPANfile");
if (eval { require CPAN::Meta::Check; 1 }) {
my $prereqs = Module::CPANfile->load->prereqs;
my @err = CPAN::Meta::Check::verify_dependencies($prereqs, [qw/runtime build test develop/], 'requires');
for (@err) {
warn "Warning: $_\n";
}
} else {
warn "CPAN::Meta::Check is not installed. Skipping dependencies check for the author.\n";
App-Env
view release on metacpan or search on metacpan
is( App::Env->new( 'App1' )->env->{Site1_App1}, 1, 'import App1, id => default' );
is( App::Env->new( 'App1', { CacheID => 'foo' } )->env->{Site1_App1},
2, 'import App1, id => "foo"' );
# verify that the old one is still cached.
is( App::Env->new( 'App1' )->env->{Site1_App1}, 1, 're-import App1, id => default' );
# and now try for foo again
is( App::Env->new( 'App1', { CacheID => 'foo' } )->env->{Site1_App1},
2, 're-import App1, id => "foo"' );
App-EventStreamr
view release on metacpan or search on metacpan
share/status/app/lib/angular/angular-cookies.js view on Meta::CPAN
$browser.cookies(name, value);
updated = true;
}
}
//verify what was actually stored
if (updated){
updated = false;
browserCookies = $browser.cookies();
for (name in cookies) {
App-FargateStack
view release on metacpan or search on metacpan
lib/App/FargateStack.pm view on Meta::CPAN
my ( $cluster, $tasks ) = $self->common_args(qw(cluster tasks));
my $cluster_name = $cluster->{name};
$self->verify_service($service_name);
require Text::Wrap;
Text::Wrap->import('wrap');
{
lib/App/FargateStack.pm view on Meta::CPAN
my ( $config, $cluster, $dryrun ) = $self->common_args(qw(config cluster dryrun));
my $cluster_name = $cluster->{name};
$self->verify_service($task_name);
$self->check_task( $task_name, 'warn' );
$self->log_warn( 'remove-service: task [%s] will be deleted...%s', $task_name, $dryrun );
lib/App/FargateStack.pm view on Meta::CPAN
return $SUCCESS;
}
########################################################################
sub verify_service {
########################################################################
my ( $self, $service_name ) = @_;
my ( $cluster, $config ) = $self->common_args(qw(cluster config));
lib/App/FargateStack.pm view on Meta::CPAN
my ($cluster) = $self->common_args(qw(cluster));
my $cluster_name = $cluster->{name};
$self->verify_service($service_name);
my $ecs = $self->fetch_ecs;
my $task_definition_arn = $self->get_latest_task_definition($service_name);
lib/App/FargateStack.pm view on Meta::CPAN
my ( $config, $cluster ) = $self->common_args(qw(config cluster));
my $cluster_name = $cluster->{name};
$self->verify_service($task_name);
my $ecs = $self->get_ecs;
my $result = $ecs->update_service(
cluster_name => $cluster_name,
App-FastishCGI
view release on metacpan or search on metacpan
This file contains message digests of all files listed in MANIFEST,
signed via the Module::Signature module, version 0.68.
To verify the content in this distribution, first make sure you have
Module::Signature installed, then type:
% cpansign -v
It will check each file's integrity, as well as the signature's
App-Fetchware
view release on metacpan or search on metacpan
lib/App/Fetchware.pm view on Meta::CPAN
gpg_keys_url
gpg_sig_url
sha1_url
md5_url
user_agent
verify_method
no_install
verify_failure_ok
user_keyring
stay_root
mirror
config
lib/App/Fetchware.pm view on Meta::CPAN
new_install
check_syntax
start
lookup
download
verify
unarchive
build
install
end
uninstall
lib/App/Fetchware.pm view on Meta::CPAN
)],
OVERRIDE_DOWNLOAD => [qw(
determine_package_path
)],
OVERRIDE_VERIFY => [qw(
gpg_verify
sha1_verify
md5_verify
digest_verify
)],
OVERRIDE_UNARCHIVE => [qw(
check_archive_files
list_files
list_files_tar
lib/App/Fetchware.pm view on Meta::CPAN
[ gpg_keys_url => 'ONE' ],
[ gpg_sig_url => 'ONE' ],
[ sha1_url => 'ONE' ],
[ md5_url => 'ONE' ],
[ user_agent => 'ONE' ],
[ verify_method => 'ONE' ],
[ mirror => 'MANY' ],
[ no_install => 'BOOLEAN' ],
[ verify_failure_ok => 'BOOLEAN' ],
[ stay_root => 'BOOLEAN' ],
[ user_keyring => 'BOOLEAN' ],
);
lib/App/Fetchware.pm view on Meta::CPAN
md5_url => <<EOA,
md5_url specfies the url that fetchware uses to download md5sum files of
this program. This url should be the program's main download site instead of a
mirror, because a hacked mirror could alter the md5sum on that mirror.
EOA
verify_method => <<EOA,
verify_method specifes a specific method that fetchware should use to verify
your program. This method can be 'gpg', 'sha1', or 'md5'.
EOA
no_install => <<EOA,
no_install specifies that this software should not be installed. Instead, the
install step is skipped, and fetchware prints to STDOUT where it downloaded,
verified, and built your program. no_install must be a true or false value.
EOA
verify_failure_ok => <<EOA,
verify_failure_ok specifies that fetchware should not stop installing your
software and terminate with an error message if fetchware fails to verify your
software. You should never set this to true. Doing so could cause fetchware to
install software that may have been compromised, or had malware inserted into
it. Never use this option unless the author or maintainer of this program does
not gpg sign or checksum his software.
EOA
lib/App/Fetchware.pm view on Meta::CPAN
my $mirrors_hashref = get_mirrors($term, $filename_listing);
vmsg "Added mirrors to your Fetchwarefile.";
vmsg Dumper($mirrors_hashref);
my $verify_hashref = get_verification($term, $filename_listing, $lookup_url);
vmsg "Added verification settings to Fetchwarefile.";
vmsg Dumper($verify_hashref);
my $filter_hashref = get_filter_option($term, $filename_listing);
vmsg "Added [$filter_hashref->{filter}] filter setting to Fetchwarefile.";
$fetchwarefile->config_options(
%$mirrors_hashref,
%$verify_hashref,
%$filter_hashref
);
###BUGALERT### Ask to parrallelize make with make_options???
###BUGALERT### Verify prefix is writable by current user, who will
lib/App/Fetchware.pm view on Meta::CPAN
What gpg_sig_url configuration option would you like?
EOP
print_me => <<EOP
gpg_sig_url specifies a url similar to lookup_url in that it should specify a
directory instead a specific file. It is used to download gpg signatures to
verify your software package.
EOP
},
sha1_url => {
prompt => <<EOP,
What sha1_url configuration option would you like?
lib/App/Fetchware.pm view on Meta::CPAN
you should download software from mirrors, but checksums from the original
vendor's server, because checksums are easily replaced on a mirror by a hacker
if the mirror gets hacked.
EOP
},
verify_method => {
prompt => <<EOP,
What verify_method configuration option would you like?
EOP
print_me => <<EOP,
verify_method specifies what method of verification fetchware should use to
ensure the software you have downloaded has not been tampered with. The default
is to try gpg verification, then sha1, and then finally md5, and if they all
fail an error message is printed and fetchware exits, because if your software
package cannot be verified, then it should not be installed. This configuration
option allows you to remove the warnings by specifying a specific way of
verifying your software has not been tampered with. To disable verification set
the 'verify_failure_ok' configuration option to true.
EOP
},
###BUGALERT### replace no_install config su with a command line option that
#would be the opposite of --force???
# Nah! Leave it! Just create a command line option for it too!
lib/App/Fetchware.pm view on Meta::CPAN
###BUGALERT### no_install is not currently implemented properly!!!
print_me => <<EOP
no_install is a true or false option, whoose acceptable values include 1
or 0, true or falue, On or Off. It's default value is false, but if you enable
it, then fetchware will not install your software package, and instead it will
simply download, verify, and build it. And then it will print out the full path
of the directory it built your software package in.
EOP
###BUGALERT### Add support for a check regex, so that I can ensure
#that what the user enters will be either true or false!!!
},
verify_failure_ok => {
prompt => <<EOP,
Would you like to enable the verify_failure_ok configuration option?
EOP
print_me => <<EOP
verify_failure_ok is a true or false option, whoose acceptable values include 1
or 0, true or falue, On or Off. It's default value is false, but if you enable
it, then fetchware will not print an error message and exit if verification
fails for your software package. Please note that you should never use this
option, because it makes it possible for fetchware to install source code that
may have been tampered with.
lib/App/Fetchware.pm view on Meta::CPAN
sub get_verification {
my ($term, $filename_listing, $lookup_url) = @_;
my %options;
my %available_verify_methods;
# Determine what types of verification are available.
for my $file_and_timestamp (@$filename_listing) {
if ($file_and_timestamp->[0] =~ /\.(asc|sig|sign)$/) {
$available_verify_methods{gpg}++;
} elsif ($file_and_timestamp->[0] =~ /\.sha1?$/) {
$available_verify_methods{sha1}++;
} elsif ($file_and_timestamp->[0] =~ /\.md5$/) {
$available_verify_methods{md5}++;
}
}
my $verify_configed_flag = 0;
#If gpg is available prefer it over the others.
if (exists $available_verify_methods{gpg}
and defined $available_verify_methods{gpg}
and $available_verify_methods{gpg} > 0
) {
msg <<EOM;
gpg digital signatures found. Using gpg verification.
EOM
$options{verify_method} = 'gpg';
# Search for a KEYS file to use to import the author's keys.
if (grep {$_->[0] eq 'KEYS'} @$filename_listing) {
msg <<EOM;
KEYS file found using lookup_url. Adding gpg_keys_url to your Fetchwarefile.
lib/App/Fetchware.pm view on Meta::CPAN
uri_split($lookup_url);
$path = catfile($path, 'KEYS');
$lookup_url = uri_join($scheme, $auth, $path, $query, $fragment);
$options{gpg_keys_url} = $lookup_url;
$verify_configed_flag++;
} else {
msg <<EOM;
KEYS file *not* found!
EOM
# Since autoconfiguration of KEYS failed, try asking the user if
lib/App/Fetchware.pm view on Meta::CPAN
EOP
)
) {
$options{user_keyring} = 'On';
$verify_configed_flag++;
}
# And if the user does not want to, then fallback to sha1 and/or md5
# if they're defined, which is done below.
}
}
# Only try sha1 and md5 if gpg failed.
unless ($verify_configed_flag == 1) {
if (exists $available_verify_methods{sha1}
and defined $available_verify_methods{sha1}
and $available_verify_methods{sha1} > 0
) {
msg <<EOM;
SHA1 checksums found. Using SHA1 verification.
EOM
$options{verify_method} = 'sha1';
} elsif (exists $available_verify_methods{md5}
and defined $available_verify_methods{md5}
and $available_verify_methods{md5} > 0
) {
msg <<EOM;
MD5 checksums found. Using MD5 verification.
EOM
$options{verify_method} = 'md5';
} else {
# Print a huge long nasty warning even include links to news stories
# of mirrors actually getting hacked and serving malware, which
# would be detected and prevented with proper verification enabled.
# Ask user if they would like to continue installing fetchware even if
# verification fails, and then enable the verify_failure_ok option.
if (
$term->ask_yn(prompt => <<EOP,
Would you like fetchware to ignore the fact that it is unable to verify the
authenticity of any downloads it makes? Are you ok with possibly downloading
viruses, worms, rootkits, or any other malware, and installing it possibly even
as root?
EOP
default => 'n',
print_me => <<EOP,
Automatic verification of your fetchware package has failed! Fetchware is
capable of ignoring the error, and installing software packages anyway using its
verify_failure_ok configuration option. However, installing software packages
without verifying that they have not been tampered with could allow hackers to
potentially install malware onto your computer. Don't think this is *not*
possible or do you think its extremely unlikely? Well, it's actually
surprisingly common:
1. http://arstechnica.com/security/2012/09/questions-abound-as-malicious-phpmyadmin-backdoor-found-on-sourceforge-site/
Discusses how a mirror for sourceforge was hacked, and the phpMyAdmin
lib/App/Fetchware.pm view on Meta::CPAN
4. http://www.theregister.co.uk/2011/03/21/php_server_hacked/
Discusses how php's wiki.php.org server was hacked yielding credentials to
php's source code repository.
Download mirrors *do* get hacked. Do not make the mistake, and think that it is
not possible. It is possible, and it does happen, so please properly configure
your Fetchwarefile to enable fetchware to verify that the downloaded software is
the same what the author uploaded.
EOP
)
) {
# If the user is ok with not properly verifying downloads, then
# ignore the failure, and install anyway.
$options{verify_failure_ok} = 'On';
} else {
# Otherwise, throw an exception.
die <<EOD;
fetchware: Fetchware *must* be able to verify any software packages that it
downloads. The Fetchwarefile that you were creating could not do this, because
you failed to specify how fetchware can verify its downloads. Please rerun
fetchware new again, and this time be sure to specify a gpg_keys_url, specify
user_keyring to use your own gpg keyring, or answer yes to the question
regarding adding verify_failure_ok to your Fetchwarefile to make failing
verificaton acceptable to fetchware.
EOD
}
}
}
lib/App/Fetchware.pm view on Meta::CPAN
}
sub verify {
my ($download_path, $package_path) = @_;
msg "Verifying the downloaded package [$package_path]";
my $retval;
unless (defined(config('verify_method'))) {
# if gpg fails try
# sha and if it fails try
# md5 and if it fails die
msg 'Trying to use gpg to cyptographically verify downloaded package.';
my ($gpg_err, $sha_err, $md5_err);
eval {$retval = gpg_verify($download_path)};
$gpg_err = $@;
if ($gpg_err) {
msg <<EOM;
Cyptographic verification using gpg failed!
GPG verification error [
lib/App/Fetchware.pm view on Meta::CPAN
}
if (! $retval or $gpg_err) {
msg <<EOM;
Trying SHA1 verification of downloaded package.
EOM
eval {$retval = sha1_verify($download_path, $package_path)};
$sha_err = $@;
if ($sha_err) {
msg <<EOM;
SHA1 verification failed!
SHA1 verificaton error [
lib/App/Fetchware.pm view on Meta::CPAN
}
if (! $retval or $sha_err) {
msg <<EOM;
Trying MD5 verification of downloaded package.
EOM
eval {$retval = md5_verify($download_path, $package_path)};
$md5_err = $@;
if ($md5_err) {
msg <<EOM;
MD5 verification failed!
MD5 verificaton error [
lib/App/Fetchware.pm view on Meta::CPAN
EOM
warn $md5_err;
}
}
if (! $retval or $md5_err) {
die <<EOD unless config('verify_failure_ok');
App-Fetchware: run-time error. Fetchware failed to verify your downloaded
software package. You can rerun fetchware with the --force option or add
[verify_failure_ok 'True';] to your Fetchwarefile. See the section VERIFICATION
FAILED in perldoc fetchware.
EOD
}
if (config('verify_failure_ok')) {
warn <<EOW;
App-Fetchware: run-time warning. Fetchware failed to verify the integrity of you
downloaded file [$package_path]. This is ok, because you asked Fetchware to
ignore its errors when it tries to verify the integrity of your downloaded file.
You can also ignore the errors Fetchware printed out abover where it tried to
verify your downloaded file. See perldoc App::Fetchware.
EOW
vmsg <<EOM;
Verification Failed! But you asked to ignore verification failures, so this
failure is not fatal.
EOM
return 'warned due to verify_failure_ok'
}
}
} elsif (config('verify_method') =~ /gpg/i) {
vmsg <<EOM;
You selected gpg cryptographic verification. Verifying now.
EOM
###BUGALERT### Should trap the exception {gpg,sha1,md5}_verify()
#throws, and then add that error to the one here, otherwise the
#error message here is never seen.
gpg_verify($download_path)
or die <<EOD unless config('verify_failure_ok');
App-Fetchware: run-time error. You asked fetchware to only try to verify your
package with gpg or openpgp, but they both failed. See the warning above for
their error message. See perldoc App::Fetchware.
EOD
} elsif (config('verify_method') =~ /sha1?/i) {
vmsg <<EOM;
You selected SHA1 checksum verification. Verifying now.
EOM
sha1_verify($download_path, $package_path)
or die <<EOD unless config('verify_failure_ok');
App-Fetchware: run-time error. You asked fetchware to only try to verify your
package with sha, but it failed. See the warning above for their error message.
See perldoc App::Fetchware.
EOD
} elsif (config('verify_method') =~ /md5/i) {
vmsg <<EOM;
You selected MD5 checksum verification. Verifying now.
EOM
md5_verify($download_path, $package_path)
or die <<EOD unless config('verify_failure_ok');
App-Fetchware: run-time error. You asked fetchware to only try to verify your
package with md5, but it failed. See the warning above for their error message.
See perldoc App::Fetchware.
EOD
} else {
die <<EOD;
App-Fetchware: run-time error. Your fetchware file specified a wrong
verify_method option. The only supported types are 'gpg', 'sha', 'md5', but you
specified [@{[config('verify_method')]}]. See perldoc App::Fetchware.
EOD
}
msg 'Verification succeeded.';
}
sub gpg_verify {
my $download_path = shift;
my $keys_file;
# Attempt to download KEYS file in lookup_url's containing directory.
# If that fails, try gpg_keys_url if defined.
# Import downloaded KEYS file into a local gpg keyring using gpg command.
# Determine what URL to use to download the signature file *only* from
# lookup_url's host, so that we only download the signature from the
# project's main mirror.
# Download it.
# gpg verify the sig using the downloaded and imported keys in our local
# keyring.
# Skip downloading and importing keys if we're called from inside a
# fetchware package, which should already have a copy of our package's
# KEYS file.
lib/App/Fetchware.pm view on Meta::CPAN
$keys_file = no_mirror_download_file(config('lookup_url'). '/KEYS');
};
die <<EOD if $@;
App-Fetchware: Fetchware was unable to download the gpg_key_url you specified or
that fetchware tried appending asc, sig, or sign to [@{[config('lookup_url')]}].
It needs to download this file to properly verify you software package. This is
a fatal error, because failing to verify packages is a perferable default over
potentially installing compromised ones. If failing to verify your software
package is ok to you, then you may disable verification by adding
verify_failure_ok 'On'; to your Fetchwarefile. See perldoc App::Fetchware.
EOD
}
# Import downloaded KEYS file into a local gpg keyring using gpg
# command.
lib/App/Fetchware.pm view on Meta::CPAN
last if defined $sig_file;
}
die <<EOD if not defined $sig_file;
App-Fetchware: Fetchware was unable to download the gpg_sig_url you specified or
that fetchware tried appending asc, sig, or sign to [$sig_url]. It needs
to download this file to properly verify you software package. This is a fatal
error, because failing to verify packages is a perferable default over
potentially installing compromised ones. If failing to verify your software
package is ok to you, then you may disable verification by adding
verify_failure_ok 'On'; to your Fetchwarefile. See perldoc App::Fetchware.
EOD
###BUGALERT### # Use Crypt::OpenPGP if its installed.
###BUGALERT### if (eval {use Crypt::OpenPGP}) {
##DOESNTWORK?? # Build a pubring needed for verify.
##DOESNTWORK?? my $pubring = Crypt::OpenPGP::KeyRing->new();
##DOESNTWORK?? my $secring = Crypt::OpenPGP::KeyRing->new();
##DOESNTWORK??
##DOESNTWORK?? # Turn on gpg compatibility just in case its needed.
##DOESNTWORK?? my $pgp = Crypt::OpenPGP->new(
lib/App/Fetchware.pm view on Meta::CPAN
##DOESNTWORK?? # Use this keyserver to download them from.
##DOESNTWORK?? KeyServer => 'pool.sks-keyservers.net',
##DOESNTWORK?? );
##DOESNTWORK??
##DOESNTWORK?? # Verify the downloaded file.
##DOESNTWORK?? my $retval = $pgp->verify(SigFile => $sig_file, Files => $CONFIG{PackagePath});
##DOESNTWORK?? if ($retval == 0) {
##DOESNTWORK?? warn "Crypt::OpenPGP failed due to invalid signature.";
##DOESNTWORK?? # return failure, because Fetchware failed to verify the downloaded
##DOESNTWORK?? # file.
##DOESNTWORK?? return undef;
##DOESNTWORK?? } elsif ($retval) {
##DOESNTWORK?? return 'Package verified';
##DOESNTWORK?? } else {
##DOESNTWORK?? # print warning about $pgp errstr message.
##DOESNTWORK?? my $errstr = $pgp->errstr();
##DOESNTWORK?? warn "Crypt::OpenPGP failed with message: [$errstr]";
##DOESNTWORK?? # return failure, because Fetchware failed to verify the downloaded
##DOESNTWORK?? # file.
##DOESNTWORK?? return undef;
##DOESNTWORK?? }
###BUGALERT### } else {
###BUGALERT### ###BUGALERT### eval the run_prog()'s below & add better error reporting in
lib/App/Fetchware.pm view on Meta::CPAN
#my standard format.
# Use automatic key retrieval & a cool pool of keyservers
###BUGALERT## Give Crypt::OpenPGP another try with
#pool.sks-keyservers.net
###BUGALERT### Should I cache the files gpg puts in its "homedir"? They
#are the public keys that verify this fetchware package. Or should they
#always be downloaded on demand as they are now??? But if verify() can
#have keys cached inside the fetchware package does that mean that I
#should open up this as an API for fetchware extensions????? I don't
#know. I'll have to think more about this issue.
#run_prog('gpg', '--keyserver', 'pool.sks-keyservers.net',
# '--keyserver-options', 'auto-key-retrieve=1',
# '--homedir', '.', "$sig_file");
# Verify sig.
# Add --homedir option if needed.
if (config('user_keyring')) {
run_prog('gpg', '--verify', $sig_file);
} else {
run_prog('gpg', '--homedir', '.', '--verify', $sig_file);
}
# Return true indicating the package was verified.
return 'Package Verified';
}
sub sha1_verify {
my ($download_path, $package_path) = @_;
return digest_verify('SHA-1', $download_path, $package_path);
}
sub md5_verify {
my ($download_path, $package_path) = @_;
return digest_verify('MD5', $download_path, $package_path);
}
sub digest_verify {
my ($digest_type, $download_path, $package_path) = @_;
# Turn SHA-1 into sha1 & MD5 into md5.
my $digest_ext = $digest_type;
$digest_ext = lc $digest_type;
lib/App/Fetchware.pm view on Meta::CPAN
$digest_file = no_mirror_download_file("$digest_url.$digest_ext");
};
if ($@) {
die <<EOD;
App-Fetchware: Fetchware was unable to download the $digest_type sum it needs to
download to properly verify you software package. This is a fatal error, because
failing to verify packages is a perferable default over potentially installin
compromised ones. If failing to verify your software package is ok to you, then
you may disable verification by adding verify_failure_ok 'On'; to your
Fetchwarefile. See perldoc App::Fetchware.
EOD
}
}
lib/App/Fetchware.pm view on Meta::CPAN
# Search the @fields for a regex that is either 32 hex for md5 or 40 hex
# for sha1.
my ($checksum) = grep /^[0-9a-f]{32}(?:[0-9a-f]{8})?$/i, @fields;
# Skip trying to verify the $checksum if we failed to find it in this
# line, and instead skip to the next line in the checksum file to try to
# find a $checksum.
next unless defined $checksum;
if ($checksum eq $calculated_digest) {
lib/App/Fetchware.pm view on Meta::CPAN
return 'Package verified';
}
}
close $digest_fh;
# Return failure, because fetchware failed to verify by checksum
return undef;
}
lib/App/Fetchware.pm view on Meta::CPAN
Mandatory => [ 'lookup_url', <<EOM ],
App-Fetchware: Your Fetchwarefile must specify a lookup_url configuration
option. Please add one, and try again.
EOM
ConfigOptionEnum => ['lookup_method', [qw(timestamp versionstring)] ],
ConfigOptionEnum => ['verify_method', [qw(gpg sha1 md5)] ],
);
}
lib/App/Fetchware.pm view on Meta::CPAN
App::Fetchware represents fetchware's API. For ducumentation on how to use
App::Fetchware's fetchware command line interface see L<fetchware>.
It is the heart and soul of fetchware where all of fetchware's main behaviors
are kept. It is fetchware's API, which consists of the subroutines new(),
new_install(), check_syntax(), start(), lookup(), download(), verify(),
unarchive(), build(), install(), uninstall(), upgrade() and end().
App::Fetchware stores both details about C<fetchware>'s configuration file
syntax, documents how to create a fetchware extension, and documents the
internal workings of how App::Fetchware implements C<fetchware>'s package
lib/App/Fetchware.pm view on Meta::CPAN
At the heart of App::Fetchware is its C<lookup_url>, which is
the URL to the FTP or HTTP mirror you want App::Fetchware to use to obtain a
directory listing to see if a new version of your program is available for
download. To figure this out just use your browser to find the program you
want fetchware to manage for you's Web site. Skip over the download link, and
instead look for the gpg, sha1, or md5 verify links, and copy and paste one of
those between the single quotes above in the lookup_url. Then delete the file
portion--from right to left until you reach a C</>. This is necessary, because
fetchware uses the lookup_url as a basis to download your the gpg, sha1, or md5
digital signatures or checksums to ensure that the packages fetchware downloads
and installs are exactly the same as the ones the author uploads.
lib/App/Fetchware.pm view on Meta::CPAN
Verification of software downloads is mandatory, because fetchware, in order to
install the software that is downloaded, must execute the build and installation
scripts on your computer sometimes even as the root administrator! Therefore,
fetchware will refuse to build and install any software package that cannot be
verified. This limitation can be bypassed by setting the C<verify_failure_ok>
configuration option to true, but this is B<not> recommended.
Instead, if standard verification fails, please set up one or more of the
configuration options below that may allow verification to succeed if the author
has his download site set up differently then fetchware expects.
lib/App/Fetchware.pm view on Meta::CPAN
=over
=item B<temp_dir> - Specifies the temporary directory fetchware will use to create its own working temporary directory where it downloads, unarchives, builds, and then installs your program from a directory inside this directory.
=item B<user> - (UNIX only) - Specifies a non-root user to drop privileges to when downloading, verifying, unarchive, and building your program. Root priveedges are kept in the parent process for install if needed.
=item B<prefix> - Specifies the --prefix option for AutoTools (./configure) based programs.
=item B<configure_options> - Specifies any additional options that fetchware should give to AutoTools when it runs ./configure to configure your program before it is built and installed.
lib/App/Fetchware.pm view on Meta::CPAN
=head2 program 'Program Name';
C<program> simply gives this Fetchwarefile a name. It is availabe to fetchware
after parsing your Fetchwarefile, and is used to name your Fetchwarefile when
using C<fetchware new>. It is required just like C<lookup_url>, C<mirror>,
perhaps C<filter>, and some method to verify downloads are.
=head2 filter 'perl regex here';
Specifies a Perl regular expression that fetchware uses when it determines what
the latest version of a program is. It simply compares each file in the
lib/App/Fetchware.pm view on Meta::CPAN
whatever is in the weird httpd-deps-* package.
=head2 temp_dir '/tmp';
C<temp_dir> tells fetchware where to store fetchware's temporary working
directory that it uses to download, verify, unarchive, build, and install your
software. By default it uses your system temp directory, which is whatever
directory L<File::Temp's> tempdir() decides to use, which is whatever
L<File::Spec>'s tmpdir() decides to use.
=head2 fetchware_db_path '~/.fetchwaredb';
lib/App/Fetchware.pm view on Meta::CPAN
=over
=item 1. To determine what the actual download url is for the latest version of this program
=item 2. As the base url to also download a cryptographic signature (ends in .asc) or a SHA-1 or MD5 signature to verify the contents match what the SHA-1 or MD5 checksum is.
=back
You can use the C<mirror> configuration option to specify additional mirrors.
However, those mirrors will only be used to download the large software
archives. Only the lookup_url will be used to download directory listings to
check for new versions, and to download digital signatures or checksums to
verify downloads.
=head2 lookup_method 'timestamp';
Fetchware has two algorithms it uses to determine what version of your program
to download:
lib/App/Fetchware.pm view on Meta::CPAN
=head2 gpg_keys_url 'lookup_url.com/some/path';
Specifies a file not a directory URL for a C<KEYS> file that lists all of the
authors' gpg keys for fetchware to download and import before using them to
verify the downloaded software package.
If you come accross a software package whoose author uses gpg to sign his
software packages, but he does not include it in the form of a file on his main
mirror, then you can specify the C<user_keyring> option. This option forces
fetchware to use the user who runs fetchware's keyring instead of fetchware's
own keyring. This way you can then import the author's key into your own
keyring, and have fetchware use that keyring that already has the author's key
in it to verify your downloads.
=head2 user_keyring 'On';
When enabled fetchware will use the user who runs fetchware's keyring instead of
fetchware's own keyring. Fetchware uses its own keyring to avoid adding cruft to
your own keyring.
This is needed when the author of a software package does not maintain a KEYS
file that can easily be downloaded and imported into gpg. This option allows you
to import the author's key manually into your own gpg keyring, and then
fetchware will use your own keyring instead of its own to verify your downloads.
=over
=item LIMITAITON
lib/App/Fetchware.pm view on Meta::CPAN
programs and authors use these extensions too.
=head2 sha1_url 'mastermirror.com/some/path';
Specifies an alternate url to download the SHA-1 checksum. This checksum is used
to verify the integrity of the archive that fetchware downloads.
You B<must> specify the master mirror site, which is your programs main mirror
site, because if you download it from a mirror, its possible that both the
archive and the checksum could have been tampered with.
=head2 md5_url 'mastermirror.com/some/path';
Specifies an alternate url to download the MD5 checksum. This checksum is used
to verify the integrity of the archive that fetchware downloads.
You B<must> specify the master mirror site, which is your programs main mirror
site, because if you download it from a mirror, its possible that both the
archive and the checksum could have been tampered with.
lib/App/Fetchware.pm view on Meta::CPAN
Specifies what C<user_agent> you would like fetchware to pretend to be when
downloading files using the HTTP protocol. Some sites annoying prevent some
user agents from working while allowing others. This allows you to pretend to
be a real browser such as Firefox if you need to.
=head2 verify_method 'gpg';
Chooses a method to verify your program. The default is to try C<gpg>, then
C<sha1>, and finally C<md5>, and if all three fail, then the default is to exit
fetchware with an error message, because it is insecure to install archives that
cannot be verified. The availabel options are:
=over
=item gpg - Uses the gpg program to cryptographically verify that the program you downloaded is exactly the same as its author uploaded it.
=item sha1 - Uses the SHA-1 hash function to verify the integrity of the download. This is much less secure than gpg.
=item md5 - Uses the MD5 hash function to verify the integrity of the download. This is much less secure than gpg.
=back
=head2 verify_failure_ok 'True';
Fetchware's default regarding failing to verify your downloaded Archive with
gpg, sha1, or md5 is to exit with an error message, because installing software
that cannot be cryptographically verified should never be done.
=over
=item SECURITY NOTICE
However, if the author of a program you want to use fetchware to manage for you
does not offer a gpg, sha1, or md5 file to verify its integrity, then you can
use this option to force Fetchware to install this program anyway. However, do
not enable this option lightly. Please scour the program's mirrors and homepage
to see which C<gpg_keys_url>, C<gpg_sig_url>, C<sha1_url>, C<md5_url>, or
C<user_keyring> you can use to ensure that your archive is verified before it is
compiled and installed. Even mirrors from sites large and small get hacked
lib/App/Fetchware.pm view on Meta::CPAN
=over
=item NOTICE
C<verify_failure_ok> is a boolean configuration option, which just means its
values are limited to either true or false. True values are C<'True'>, C<'On'>,
C<1>, and false values are C<'False'>, C<'Off'>, and C<0>. All other values are
syntax errors.
=back
lib/App/Fetchware.pm view on Meta::CPAN
L</lookup_by_versionstring()>, L</lookup_determine_downloadpath()>
=item L<OVERRIDE_DOWNLOAD|download() API REFERENCE> -
L</determine_package_path()>
=item L<OVERRIDE_VERIFY|verify() API REFERENCE> - L</gpg_verify()>,
L</sha1_verify()>, L</md5_verify()>, L</digest_verify()>
=item L<OVERRIDE_UNARCHIVE|unarchive() API REFERENCE> -
L</check_archive_files()>, L</list_files()>, L</list_files_tar()>,
L</list_files_zip()>, L</unarchive_package()>, L</unarchive_tar()>,
L</unarchive_zip()>
lib/App/Fetchware.pm view on Meta::CPAN
filter 'httpd-2.2';
mirror 'http://apache.mirrors.pair.com/httpd/';
mirror 'http://mirrors.ibiblio.org/apache/httpd/';
mirror 'ftp://apache.cs.utah.edu/apache.org/httpd/';
verify_method 'gpg';
gpg_keys_url 'http://www.apache.org/dist/httpd/KEYS';
make_options '-j 4';
prefix '/home/dly/software/apache2.2';
# You can use heredocs to make gigantic options like this one more legible.
lib/App/Fetchware.pm view on Meta::CPAN
configuration is supported. Next, nginx does not have a KEYS file, but it does
list it's developer's keys on its Website. So, they have to be imported manually
into your keyring, and then specify the C<user_keyring> option to switch
fetchware from usings its own keyring to using your own keyring. Also, note the
comment regarding having to use the C<user> option to specify a real user
account. This is needed, because the verify step is done by fetchware's child
after that child drops its root privileges. Th default user is nobody, and
nobody has no real home, and therefore no keyring, so gpg won't be able to read
the keys you ask it to by using the C<user_keyring> option; therefore, C<user>
must be specified to change it to a real user, whoose keyring has had these keys
imported into it. Also, worth noting that this nginx configuration does not use
lib/App/Fetchware.pm view on Meta::CPAN
user 'dly';
# The other option, which is commented out below, is to use root's own keyring,
# and the no_install option to ensure that root uses its own keyring instead of
# nobody's.
# noinstall 'On';
verify_method 'gpg';
=back
=head2 PHP Programming Language
PHP annoyingly uses a custom Web application on each of its mirror sites to
serve HTTP downloads. No simple directory listing is available. Therefore, to
use php with fetchware, custom C<lookup>, C<download>, and C<verify> hooks are
needed that override fetchware's internal behavior to customize fetchware as
needed so that it can work with how PHP's site is up.
The C<lookup> hook downloads and parses the L<http://www.php.net/downloads.php>
page, which lists files availabe for download. This file is parsed using
L<HTML::TreeBuilder> to determine the latest version. The MD5 sum is also parsed
out to verify the downloaded file as well.
The C<download> hook is only needed, because http_download_file() presumes that
the last part of the path is the filename you're downloading. And this is
annoyingly not the case with the way PHP has its downloading system set up.
The C<verify> hook just uses L<Digest::MD5> to calculate the md5sum of the
downloaded file, and compares it with the one C<lookup> parses out.
=over
use App::Fetchware qw(
lib/App/Fetchware.pm view on Meta::CPAN
php.Fetchwarefile: A path should be found in this link [$link], but there is no
path it in. No href [$h->{href}].
EOD
}
# Find and save the $md5sum for the verify hook below.
# It should be 6 elements over, so it should be the sixth index
# in the @right array below (remember to start counting from 0.).
my @right = $h->right();
my $md5_span_tag = $right[5];
$md5sum = $md5_span_tag->as_text();
lib/App/Fetchware.pm view on Meta::CPAN
return $package_path
};
# The above lookup hook parses out the md5sum on the php downloads.php web
# site, and stores it in $md5sum, which is used in the the verify hook below.
hook verify => sub {
# Don't need the $download_path, because lookup above did that work for us.
# $package_path is the actual php file that we need to ensure its md5
# matches the one lookup determined.
my ($download_path, $package_path) = @_;
msg "Verifying [$package_path] using md5.";
dir <<EOD if not defined $md5sum;
php.Fetchwarefile: lookup failed to figure out the md5sum for verify to use to
verify that the php version [$package_path] matches the proper md5sum.
The md5sum was [$md5sum].
EOD
my $package_fh = safe_open($package_path, <<EOD);
php.Fetchwarefile: Can not open the php package [$package_path]. The OS error
lib/App/Fetchware.pm view on Meta::CPAN
and then it runs git tags, and ditches some older junk tags, and finds only the
tags used for new versions of php. These are sorted using the C<versonstring>
lookup() algorithm, and the latest one is returned.
download() uses C<git checkout [latesttag]> to "download" php by simply changing
the working directory to the latest tag. verify() uses git's cool C<verify-tag>
command to verify the gpg signature. unarchive() is updated to do nothing since
there is no archive to unarchive. However, because we reuse build(), archive()
must return a $build_path that build() will change its directory to. start() and
end() are also overridden, because managing a temporary directory is not needed,
so, instead, they just do a C<git checkout master> to switch from whatever the
latest tag is back to master, because git pull bases what it does on what branch
you're in, so we must actually be a real branch to update git.
=over
# php-using-git.Fetchwarefile: example fetchwarefile using php's git repo
# for lookup(), download(), and verify() functionality.
use App::Fetchware qw(:DEFAULT :OVERRIDE_LOOKUP);
use App::Fetchware::Util ':UTIL';
use Cwd 'cwd';
# The directory where the php source code's local git repo is.
lib/App/Fetchware.pm view on Meta::CPAN
# You must manually add php's developer's gpg keys to your gpg keyring. Do
# this by going to the page: http://us1.php.net/downloads.php . At the
# bottom the gpg key "names are listed such as "7267B52D" or "5DA04B5D."
# These are their key "names." Use gpg to download them and import them into
# your keyring using: gpg --keyserver pgp.mit.edu --recv-keys [key id]
hook verify => sub {
my ($download_path, $package_path) = @_;
# the latest tag is the download path see lookup.
my $latest_tag = $download_path;
# Run git verify-tag to verify the latest tag
my $success = eval { run_prog('git verify-tag', "$latest_tag"); 1;};
# If the git verify-tag fails, *and* verify_failure_ok has been turned on,
# then ignore the thrown exception, but print an annoying message.
unless (defined $success and $success) {
unless (config('verify_failure_ok')) {
msg <<EOM;
Verification failure ok, becuase you've configured fetchware to continue even
if it cannot verify its downloads. Please reconsider, because mirror and source
code repos do get hacked. The exception that was caught was:
[$@]
EOM
}
}
lib/App/Fetchware.pm view on Meta::CPAN
Like PHP MariaDB uses some annoying software on their Web site to presumably
track downloads. This software makes use of AJAX, which is vastly beyone the
capabilities of HTML::TreeBuilder to parse, because it needs a working
JavaScript environment. Therefore, the example Fetchwarefile below has no way of
verifying the MySQL downloads. This could be fixed by using a Perl Web scraping
module that can deal with JavaScript.
=over
use App::Fetchware;
lib/App/Fetchware.pm view on Meta::CPAN
my $weird_prefix = '/mariadb-' . $version_number[0] . '/kvm-tarbake-jaunty-x86/';
my $download_path = '/pub/mariadb' . $weird_prefix .$filename;
return $download_path;
};
# Make verify() failing to verify MariaDB ok, because parsing out the MD5 sum
# would require a Web scraper that supports javascript, which HTML::TreeBuilder
# obviously does not.
verify_failure_ok 'On';
# Use build_commands to configure fetchware to use MariaDB's BUILD script to
# build it. See https://mariadb.com/kb/en/generic-build-instructions/ for
# instructions on the different BUILD cmake scripts that are available.
build_commands 'BUILD/compile-pentium64-max';
lib/App/Fetchware.pm view on Meta::CPAN
my $download_path = '/pub/source/'. "v$latest_ver->[0][0]" .
"/postgresql-$latest_ver->[0][0].tar.bz2";
return $download_path;
};
# MD5sums are stored on the download site, so use them to verify the package.
verify_method 'md5';
# But they are *not* stored on the original "lookup_url" site, so I must provide
# a md5_url pointing to the download site.
md5_url $mirror;
=back
lib/App/Fetchware.pm view on Meta::CPAN
its behavior.
=head2 How the API works
When fetchware installs or upgrades something it executes the API subroutines
check_syntax(), start(), lookup(), download(), verify(), unarchive(), build(),
install(), and end() in that order. And when fetchware uninstalls an installed
package it executes the API subroutines check_syntax(), start(), unarchive(),
uninstall(), and end(). Upgrade is basically the exact same thing as install(),
but it compares version numbers using the upgrade() API subroutine. And
C<fetchware new> obviously just calls new() and new_install().
lib/App/Fetchware.pm view on Meta::CPAN
=head3 API subroutines
These are the subroutines that App::Fetchware implements, and that fetchware
uses to implement its desired behavior. They are new(), new_install(),
check_syntax(), start(), lookup(), download(), verify(), unarchive(), build(),
install(), uninstall(), upgrade(), and end(). All must be
implemented or "inherited" from App::Fetchware using L<App::Fetchware::ExportAPI> as
discussed below in L<Implement your fetchware extension.> in a App::Fetchware
L<subclass>.
lib/App/Fetchware.pm view on Meta::CPAN
=item B<my $download_url = lookup()> - Determines and returns a download url that C<download()> receives and uses to download the archive for the program.o
=item B<my $package_path = download($tempd_dir, $download_url)> - Downloads its provided $download_url argument.
=item B<verify($download_url, $package_path)> - Verifies the integrity of your downloaded archive using gpg, sha1, or md5.
=item B<my $build_path = unarchive($package_path)> - Unpacks the downloaded archive.
=item B<build($build_path)> - Configures and compiles the downloaded archive.
lib/App/Fetchware.pm view on Meta::CPAN
=over
=item B<new> = Just new() and new_install().
=item B<install> - check_syntax(), start(), lookup(), download(), verify(), unarchive(), build(), install(), and end().
=item B<upgrade> - check_syntax(), start(), lookup(), I<upgrade()>, download(),
verify(), unarchive(), build(), install(), and end().
=item B<upgrade-all> - Is the same as upgrade, because it just call upgrade for
each fetchware package that is installed in the fetchware package database.
=item B<uninstall> - You might think its just uninstall(), but it does not.
lib/App/Fetchware.pm view on Meta::CPAN
App::Fetchware's API subroutines that you would like to keep. An example.
# Use App::Fetchware::ExportAPI to set up proper exports this fetchware
# extension.
use App::Fetchware::ExportAPI KEEP => [qw(new_install start end)],
OVERRIDE => [qw(new check_syntax lookup download verify
unarchive build install uninstall upgrade)]
;
There two types of subroutines ExportAPI helps you with:
lib/App/Fetchware.pm view on Meta::CPAN
I<Examples:> C<mirror>.
=item C<BOOLEAN> - Just like C<ONE> except it will convert /off/i and /false/i
to 0 to support more than just Perl's 0 or undef being false.
I<Examples:> C<verify_failure_ok>, C<no_install>, and C<stay_root>.
=back
Additionally, there is another type of configuration option that only
App::Fetchware::CreateConfigOptions uses:
lib/App/Fetchware.pm view on Meta::CPAN
commands that don't actually install anything. It's used to test actually
installing software without actually installing any software.
=item * L<md5sum_file()|Test::Fetchware/md5sum_file()> - Used to provide a
md5sum file for make_test_dist() create software packages in order to pass
fetchware's verify checks.
=item * L<verbose_on()|Test::Fetchware/verbose_on()> - Make's all vmsg()'s
actually print to the screen even if -v or --verbose was not actually
provided on the command line. Used to aid debugging.
lib/App/Fetchware.pm view on Meta::CPAN
Only exports the subroutine determine_package_path(), which simply comcatenates
a $tempdir with a $filename to return a properl $package_path, which unarchive
later uses. This is mostly its own subroutine to better document how this is
done, and to allow easier code reuse.
=item L<verify()'s OVERRIDE_VERIFY export tag.|verify() API REFERENCE>
Exports a family of subroutines to verify via MD5, SHA1, or GPG the integrity of
your downloaded package. MD5 and SHA1 are supported for legacy reasons. All
software packages should be GPG signed for much much much better security. GPG
signatures when verified actually prove that the software package you downloaded
is exactly what the author of that software package created, whereas MD5 and
SHA1 sums just verify that you downloaded the bunch of bits in the same order
that they are stored on the server.
digest_verify() an be used to add support for any other Digest::* modules that
CPAN has a Digest based module for that correctly follow Digest's API.
=item L<unarchive()'s OVERRIDE_UNARCHIVE export tag.|unarchive() API REFERENCE>
Exports subroutines that will help you unarchive software packages in tar and
lib/App/Fetchware.pm view on Meta::CPAN
=item L<Test::Fetchware/make_test_dist()> - Creates a temporary distribution
that is used for testing. This temporary distribution contains a C<./configure>
and a C<Makefile> that create no files, but can still be executed in the
standard AutoTools way.
=item L<Test::Fetchware/md5sum_file()> - Just md5sum's a file so verify() can be
tested.
=item L<Test::Fetchware/expected_filename_listing()> - Returns a string of crazy
Test::Deep subroutines to test filename listings. Not quite as useful as the
rest, but may come in handy if you're only changing the front part of lookup().
lib/App/Fetchware.pm view on Meta::CPAN
Parses $filename_listing to determine what type of verification is available.
Prefering gpg, but falling back on sha1, and then md5 if gpg is not available.
If the type is gpg, then get_verification() will ask the user to specify a
C<gpg_keys_url>, which is required for gpg, because fetchware needs to be able
to import the needed keys to be able to use those keys to verify package
downloads. If this URL is not provided by the author, then get_verification()
will ask the user if they would like to import the author's key into their own
gpg public keyring. If they would, then get_verification() will use the
C<user_keyring> C<'On'> option to use the user's public keyring instead of
fetchware's own keyring. And if the user does not want to use their own gpg
public keyring, then get_verification will fall back to sha1 or md5 setting
C<verify_method> to sha1 or md5 as needed.
Also, adds a gpg_keys_url option if a C<KEYS> file is found in
$filename_listing.
If no verification methods are available, fetchware will print a big nasty
warning message, and offer to use C<verify_failure_ok> to make such a failure
cause fetchware to continue installing your software.
Returns a hashref of options for the user's Fetchwarefile. You're responsible
for calling append_options_to_fetchwarefile() to add them to the user's
Fetchwarefile, or perhaps the caller could analyze them in some way, before
lib/App/Fetchware.pm view on Meta::CPAN
$filename. $package_path is the path used by unarchive() to unarchive the
software distribution download() downloads.
$package_path is returned to caller.
=head2 verify()
verify($download_path, $package_path)
=over
=item Configuration subroutines used:
lib/App/Fetchware.pm view on Meta::CPAN
=item sha1_url
=item md5_url
=item verify_method
=item verify_failure_ok
=item user_agent
=back
=back
Verifies the downloaded package stored in $package_path by downloading
$download_path.{asc,sha1,md5}> and comparing the two together. Uses the
helper subroutines C<{gpg,sha1,md5,digest}_verify()>.
=over
=item LIMITATIONS
Uses gpg command line, and the interface to gpg is a little brittle.
lib/App/Fetchware.pm view on Meta::CPAN
=over
=item *
Under drop_privs() verify() is executed in the child with reduced privileges.
=back
=back
=head2 verify() API REFERENCE
The subroutines below are used by verify() to provide the verify
functionality for fetchware. If you have overridden the verify() handler, you
may want to use some of these subroutines so that you don't have to copy and
paste anything from verify().
App::Fetchware is B<not> object-oriented; therefore, you B<can not> subclass
App::Fetchware to extend it!
=head3 gpg_verify()
'Package Verified' = gpg_verify($download_path);
Uses the command-line program C<gpg> to cryptographically verify that the file
you download is the same as the file the author uploaded. It uses public-key
priviate-key cryptography. The author signs his software package using gpg or
some other OpenPGP compliant program creating a digital signature file with the
same filename as the software package, but usually with a C<.asc> file name
extension. gpg_verify() downloads the author's keys, imports them into
fetchware's own keyring unless the user sets C<user_keyring> to true in his
Fetchwarefile. Then Fetchware downloads a digital signature that usually
ends in C<.asc>. Afterwards, fetchware uses the gpg command line program to
verify the digital signature. gpg_verify returns true if successful, and throws
an exception otherwise.
You can use C<gpg_keys_url> to specify the URL of a file where the author has
uploaded his keys. And the C<gpg_sig_url> can be used to setup an alternative
location of where the C<.asc> digital signature is stored.
=head3 sha1_verify()
'Package verified' = sha1_verify($download_path, $package_path);
undef = sha1_verify($download_path, $package_path);
Verifies the downloaded software archive's integrity using the SHA Digest
specified by the C<sha_url 'ftp://sha.url/package.sha'> config option. Returns
true for sucess dies on error.
lib/App/Fetchware.pm view on Meta::CPAN
servers. To do this specify a C<sha1_url 'master.mirror/package.sha1';> in your
Fetchwarefile.
=back
=head3 md5_verify()
'Package verified' = md5_verify($download_path, $package_path);
undef = md5_verify($download_path, $package_path);
Verifies the downloaded software archive's integrity using the MD5 Digest
specified by the C<md5_url 'ftp://sha.url/package.sha'> config option. Returns
true for sucess and dies on error.
lib/App/Fetchware.pm view on Meta::CPAN
servers. To do this specify a C<md5_url 'master.mirror/package.md5';> in your
Fetchwarefile.
=back
=head3 digest_verify()
'Package verified' = digest_verify($digest_type, $download_path, $package_path);
undef = digest_verify($digest_type, $download_path, $package_path);
Verifies the downloaded software archive's integrity using the specified
$digest_type, which also determines the
C<"$digest_type_url" 'ftp://sha.url/package.sha'> config option. Returns
true for sucess and returns false for failure.
=over
=item OVERRIDE NOTE
If you need to override verify() in your Fetchwarefile to change the type of
digest used, you can do this easily, because digest_verify() uses L<Digest>,
which supports a number of Digest::* modules of different Digest algorithms.
Simply do this by override verify() to call
C<digest_verify('Digest's name for your Digest::* algorithm');>
=back
=over
lib/App/Fetchware.pm view on Meta::CPAN
=over
=item * lookup_method can only have 'timestamp' or 'versionstring'. as options.
=item * And verify_method can only have 'gpg', 'sha1', or 'md5' specified.
=back
=back
lib/App/Fetchware.pm view on Meta::CPAN
Mandatory => [ 'lookup_url', <<EOM ],
App-Fetchware: Your Fetchwarefile must specify a lookup_url configuration
option. Please add one, and try again.
EOM
ConfigOptionEnum => ['lookup_method', [qw(timestamp versionstring)] ],
ConfigOptionEnum => ['verify_method', [qw(gpg sha1 md5)] ],
);
Uses config() to test that no configuration options that clash with each other
are used.
lib/App/Fetchware.pm view on Meta::CPAN
L<App::Fetchware::ExportAPI> and L<App::Fetchware::CreateConfigOptions>. See
section L<Implement your fetchware extension.> for full details.
=head2 How do I fix the verification failed error.
Fetchware is designed to always attempt to verify the software archives it
downloads even if you failed to configure fetchware's verification settings. It
will try to guess what those setting should be using simple heuristics. First it
will try gpg verificaton, then sha1 verification, and finally md5 verification.
If all fail, then fetchware exit failure with an appropriate error message.
App-Filite-Client
view release on metacpan or search on metacpan
This file contains message digests of all files listed in MANIFEST,
signed via the Module::Signature module, version 0.87.
To verify the content in this distribution, first make sure you have
Module::Signature installed, then type:
% cpansign -v
It will check each file's integrity, as well as the signature's
( run in 2.023 seconds using v1.01-cache-2.11-cpan-13bb782fe5a )