/ 
Yukki-0.140290
/ Yukki::Manual::Installation
Security Advisories (9)
CVE-2020-11022 (2020-04-29)

In jQuery versions greater than or equal to 1.2 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

CVE-2020-11023 (2020-04-29)

In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.

CVE-2019-11358 (2019-04-20)

jQuery before 3.4.0, as used in Drupal, Backdrop CMS, and other products, mishandles jQuery.extend(true, {}, ...) because of Object.prototype pollution. If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype.

CVE-2015-9251 (2018-01-18)

jQuery before 3.0.0 is vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain Ajax request is performed without the dataType option, causing text/javascript responses to be executed.

CVE-2011-4969 (2013-03-08)

Cross-site scripting (XSS) vulnerability in jQuery before 1.6.3, when using location.hash to select elements, allows remote attackers to inject arbitrary web script or HTML via a crafted tag.

CVE-2012-6708 (2018-01-18)

jQuery before 1.9.0 is vulnerable to Cross-site Scripting (XSS) attacks. The jQuery(strInput) function does not differentiate selectors from HTML in a reliable fashion. In vulnerable versions, jQuery determined whether the input was HTML by looking for the '<' character anywhere in the string, giving attackers more flexibility when attempting to construct a malicious payload. In fixed versions, jQuery only deems the input to be HTML if it explicitly starts with the '<' character, limiting exploitability only to attackers who can control the beginning of a string, which is far less common.

CVE-2020-7656 (2020-05-19)

jquery prior to 1.9.0 allows Cross-site Scripting attacks via the load method. The load method fails to recognize and remove "<script>" HTML tags that contain a whitespace character, i.e: "</script >", which results in the enclosed script logic to be executed.

CVE-2019-5428

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as _proto_, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

CVE-2014-6071 (2018-01-16)

jQuery 1.4.2 allows remote attackers to conduct cross-site scripting (XSS) attacks via vectors related to use of the text method inside after.

NAME

Yukki::Manual::Installation - installaction instructions

VERSION

version 0.140290

SYNOPSIS

 # Install the module
 perl -MCPAN -e 'install Yukki'

 # OR better, install cpanm and run...
 cpanm Yukki

 # Setup your wiki's installation folder
 yukki-setup mysite
 cd mysite

 # Setup the repositories
 yukki-git-init main
 yukki-git-init yukki git://github.com/zostay/yukki-help.git

 # Add a user
 yukki-add-user

 # Start the server
 yukki.psgi

DESCRIPTION

The "SYNOPSIS" pretty well sums up the highlights of installation. The rest of this document discusses what each piece does and how to customize it further.

INSTALLATION

The code can be installed like any other CPAN module. By using App::cpanminus or CPAN, you will get all the dependencies downloaded and installed automatically for you.

SITE SETUP

To setup your site, you run the yukki-setup script:

yukki-setup mysite

This will create a directory named mysite in the current folder and will copy into a skeleton installation that you may customize to suit the needs of your wiki site.

In it you will find these files and directories:

  • etc/yukki.conf. This is the configuraiton file for your application. You will want to read this to make sure it is correct before continuing. The default install includes two repositories. The one named "main" is intended to be a repository for you to use to suite your needs. The one named "yukki" contains a repository of online help for the wiki software itself.

  • repositories. This directory might not exist until "REPOSITORY INITIALIZATION" is finished, but it will contain local copies o fthe git repositories that contain the wiki's files.

  • root/script. This contains all the JavaScript files served by your site. You may add to these or customize to suit your needs.

  • root/style. This contains all the CSS stylseheets served by your site. You may add to these or customize to suit your needs.

  • root/template. This contains all the templates used to render the pages for your site. You may customize these to suit your needs.

  • var/db/users. This is the directory that will contain your user database. At this point, users are stored as a colleciton of YAML formatted files.

CONFIGURATION FILE

Most of these commands (all except yukki-setup) look for a file named etc/yukki.conf in the current working directory. If this file is not found, the script checks for an environment variable named YUKKI_CONFIG, which should point to a YAML formatted configuration for your wiki site.

If no file is found, the script will stop and complain of an error.

See Yukki::Settings and Yukki::Web::Settings for a complete list of configuration directives.

REPOSITORY INITIALIZATION

Once the site directory is setup, you will need to initialize each of the git repositories that will contain the files stored by the wiki.

This is most easily performed by running:

yukki-git-init foobar

for each of the repositories. This will create a git repository that contains a single commit containing a master index file. The name of this file and the branch that it belongs to is named in the "CONFIGURATION FILE".

In addition to running this command, you may choose to run:

yukki-git-init foobar git://path/to/romote

Instead of initailizing an empty reposotiry, it will clone the named remote repository into a local mirror. This is useful if you want to sync a repository between different sites. (As of this writing, Yukki provides no help for this, but git already provides all the tools you need to do it.)

This latter command is similar to running:

git clone --mirror git://path/to/remote repositories/foobar.git

CREATE USERS

Finally, to use Yukki, you will need one or more users with access to get into your wiki. The simple way to do this is to run:

yukki-add-user

The script will ask you for information to create each user. You can then lookup the user files and edit them if you need to make later modifications.

AUTHOR

Andrew Sterling Hanenkamp <hanenkamp@cpan.org>

COPYRIGHT AND LICENSE

This software is copyright (c) 2014 by Qubling Software LLC.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.