Coder Social home page Coder Social logo

rapid7 / awsaml Goto Github PK

View Code? Open in Web Editor NEW
137.0 15.0 44.0 5.8 MB

Awsaml is an application for providing automatically rotated temporary AWS credentials.

License: MIT License

JavaScript 97.79% Ruby 0.50% HTML 1.71%
aws okta saml sso electron javascript

awsaml's Introduction

Awsaml

(https://coveralls.io/repos/github/rapid7/awsaml/badge.svg?branch=master)](https://coveralls.io/github/rapid7/awsaml?branch=master)

Awsaml is an application for providing automatically rotated temporary AWS credentials. Credentials are stored in ~/.aws/credentials so they can be used with AWS SDKs. Credentials are valid for one hour and are rotated every hour while the application's running.

In order to rotate credentials, Awsaml takes the following actions

  1. Authenticates the user with their identity provider.
  2. Reads the SAML authentication response returned from the identity provider.
  3. Generates new temporary AWS keys by calling the AssumeRoleWithSAML API.
  4. Writes the new temporary credentials to disk.

This flow repeats every hour so the user always has a valid set of AWS keys while the application's running. Awsaml reuses the SAML response from the identity provider, so the user doesn't need to reauthenticate every time.

You can grab prebuilt binaries for Mac, Linux, and Window from the releases page.

Configuration

Configuring Awsaml is a multi-step process that involves a bit of back and forth between Amazon and your identity provider. The general flow looks like this

  1. Create a SAML application in your identity provider.
  2. Create a SAML identity provider in AWS.
  3. Create an IAM role in AWS.
  4. Update the SAML application with ARNs.
  5. Run Awsaml and give it your application's metadata.

1. Create a SAML application in your identity provider

The only tested identity provider is Okta. To use Awsaml with Okta, you'll need to create a SAML 2.0 application in Okta with the following settings

SAML Settings

Name Value
Single Sign On URL http://localhost:2600/sso/saml
Recipient URL http://localhost:2600/sso/saml
Destination URL http://localhost:2600/sso/saml
Audience Restriction http://localhost:2600/sso/saml
Default Relay State
Name ID Format EmailAddress
Response Signed
Assertion Signature Signed
Signature Algorithm RSA_SHA256
Digest Algorithm SHA256
Assertion Encryption Unencrypted
SAML Single Logout Disabled
authnContextClassRef PasswordProtectedTransport
Honor Force Authentication Yes
SAML Issuer ID http://www.okta.com/${org.externalKey}

Once Okta's created your application, it will show you setup instructions.

Among those instructions will be a URL for a generated XML metadata document that will look something like this:

https://www.okta.com/app/{APP_ID}/sso/saml/metadata

Where APP_ID is the application ID Okta has assigned to your newly created app.

You should do two things with this url:

  1. Copy the url and store it somewhere locally because you will need to provide it to the Awsaml desktop application you run later.
  2. Download the contents of the url to a file on disk because you will need to supply that file when you create an identity provider in AWS.

A note on naming things (if you are using Okta)

In the next two steps, you will create and name an identity provider and a role. Be sure to choose short names (fewer than 28 characters between the two).

In the step after you create the identity provider and the role, you will need to take the ARNs for the identity provider and role and submit them to Okta. However, the field into which you will paste these values on the Okta website has a 100 character limit which is not immediately evident.

You will need to provide a string in the format:

{ROLE_ARN},{IDENTITY_PROVIDER_ARN}

The ROLE_ARN will be in this format:

arn:aws:iam::{ACCOUNT_ID}:role/{ROLE_NAME}

Where the ACCOUNT_ID is 12 digits long, and the ROLE_NAME is as long as you want it to be.

The IDENTITY_PROVIDER_ARN will be in this format:

arn:aws:iam::{ACCOUNT_ID}:saml-provider/{PROVIDER_NAME}

Where the ACCOUNT_ID is 12 digits long, and the PROVIDER_NAME is as long as you want it to be.

Thus, when combined, the two ARNs will take up 72 characters without considering the number of characters that the names have.

arn:aws:iam::XXXXXXXXXXXX:role/,arn:aws:iam::XXXXXXXXXXXX:saml-provider/

As a consequence, between the name you give to the identity provider and the name you give to the role, you can only use up to 28 characters.

2. Create a SAML identity provider in AWS

Follow Amazon's documentation for creating a SAML identity provider, in which you will need to upload the metadata document you downloaded in the previous step.

Save the ARN for your identity provider so you can configure it in your application.

3. Create an IAM role in AWS

Follow Amazon's documentation for creating an IAM role with the following modifications:

  1. In step 2 "Select Role Type"
    1. After clicking "Role for Identity Provider Access", choose "Grant API access to SAML identity providers"
  2. In step 3 "Establish Trust"
    1. For 'SAML provider', choose the provider you previous set up
    2. For 'Attribute', choose SAML:iss
    3. For 'Value', supply the Issuer URL provided by Okta when you created the application

The permissions in this role will be the ones users are granted by their the AWS tokens Awsaml generates.

Once the role's created, a trust relationship should have been established between your role and the SAML identity provider you created. If not, you will need to set up a trust relationship between it and your SAML identity provider manually. Here's an example of the JSON policy document for that relationship.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "awsKeysSAML",
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam:saml-provider"
    },
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "SAML:iss": "issuer"
      }
    }
  }]
}

Replace the "issuer" value for the "SAML:iss" key in the policy document with the issuer URL for your application. Replace the "arn:aws:iam:saml-provider" value for the "Federated" key in the policy document with the ARN for your SAML identity provider.

Save the ARN for the role so you can configure it in your application.

4. Update the SAML application with ARNs

Now that you have ARNs for the AWS identity provider and role, you can go back into Okta and add them to your application. Edit your application to include the following attributes.

Attribute Statements

Name Name Format Value
https://aws.amazon.com/SAML/Attributes/Role Unspecified arn:aws:iam:role,arn:aws:iam:provider
https://aws.amazon.com/SAML/Attributes/RoleSessionName Unspecified ${user.email}

Replace the "arn:aws:iam:role" value with the ARN of the role in AWS you created. Replace the "arn:aws:iam:provider" value with the ARN of the identity provider in AWS your created.

Multiple Role Support

To support multiple roles, add multiple values to the https://aws.amazon.com/SAML/Attributes/Role attribute. For example:

arn:aws:iam:role1,arn:aws:iam:provider
arn:aws:iam:role2,arn:aws:iam:provider
arn:aws:iam:role3,arn:aws:iam:provider

Special note for Okta users: Multiple roles must be passed as multiple values to a single attribute key. By default, Okta serializes multiple values into a single value using commas. To support multiple roles, you must contact Okta support and request that the SAML_SUPPORT_ARRAY_ATTRIBUTES feature flag be enabled on your Okta account. For more details see this post.

5. Run Awsaml and give it your application's metadata

You can find a prebuilt binary for Awsaml on the releases page. Grab the appropriate binary for your architecture and run the Awsaml application. It will prompt you for a SAML metadata URL. Enter the URL you saved in step 1. If the URL's valid, it will prompt you to log in to your identity provider. If the login's successful, you'll see temporary AWS credentials in the UI.

Building

Awsaml is built using Node and Yarn 3, so make sure you've got a compatible versions installed. Then run Yarn to install dependencies and build Awsaml.

rm -rf node_modules/
yarn install
yarn build

Those commands will create a "out" folder with zipped binaries. If you only want to create binaries for specific platforms, you can set a PLATFORM environment variable before building.

export PLATFORM=linux
yarn build

Allowed values for PLATFORM are darwin, linux and win32. You can build binaries for multiple platforms by using a comma separated list.

export PLATFORM=darwin,linux
yarn build

Similarly, if you want to specify the build architecture, you can set a ARCH environment variable before building.

export ARCH=universal
export PLATFORM=darwin
yarn build

Supported architectures are ia32, x64 , armv7l, arm64, mips64el, universal, or all.

Setup on macOS with Homebrew

A caskfile is bundled with the repository, to install Awsaml with Homebrew simply run:

wget https://raw.githubusercontent.com/rapid7/awsaml/master/brew/cask/awsaml.rb
brew install --cask awsaml.rb

There might be an error and warning prompt but it should start succesfully downloading right after When download is succesfully installed, a awsaml was successfully installed! prompt is displayed

License

Awsaml is licensed under a MIT License. See the "LICENSE.md" file for more details.

Special Thanks

awsaml's People

Contributors

agordon-r7 avatar anguyen-r7 avatar arobinson-r7 avatar asebastian avatar asebastian-r7 avatar athompson-r7 avatar bturner-r7 avatar cdoughty-r7 avatar cvita-r7 avatar davepgreene avatar devkmsg avatar dgreene-r7 avatar erran avatar erran-r7 avatar fmitchell-r7 avatar fpedrini avatar hdub-tech avatar jmartin-tech avatar jzuniga10 avatar mfreebairn-r7 avatar mkienow-r7 avatar mmurrell-r7 avatar onefrankguy avatar rdickey-r7 avatar roconnor-r7 avatar simonirwin-r7 avatar sspaeth-r7 avatar teevo avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

awsaml's Issues

Project: Confident Contributors

The goal of this project is to level up the experience of contributing to Awsaml. Contributors should be confident, which means they can

  1. Find something in Awsaml's issues they feel they can work on
  2. Get started making changes as easily as possible
  3. Know their changes won't break existing functionality
  4. Have a high degree of confidence their changes will be accepted
  5. Know when accepted changes will be released

Issues related to this project are filed under the "confident-contributors" milestone.

Provide contributing guidelines for Awsaml

So people can be confident their changes will be accepted into Awsaml, we should provide contributor guidelines in the form of a CONTRIBUTING.md document at the root of the repository. This document should include

  • instructions on formatting commit messages in code
  • guidelines for scoping changes within a pull request
  • instructions on formatting pull requests (see #22)
  • links to the documentation for testing (see #18)
  • links to the documentation for releases (see #21)

Provide a pull request template for Awsaml

So people can be confident their changes will be accepted into Awsaml, we should provide a pull rquest template in the form of a "PULL_REQUEST_TEMPLATE.md" file at the root of the project. This document should provide instructions on

  • referencing related issues
  • writing a pull request title
  • writing a pull request body
  • referencing other contributors

Add a "Recent Logins" list to the configuration page

To facilitate account switching, users need a way to log out (see #48) and a way to log back in. The current "remember the last metadata URL used" method isn't sufficient for handling multiple accounts. We should add a "Recent Logins" list to the configuration page. The list should be of the last six URLs successfully used to login.

If a URL in the "SAML Metadata URL" box is already in the list, the existing URL in the list should be moved to the top and the list length shouldn't change. If a URL in the box isn't already in the list, the URL should be added to the top of the list and the list truncated to the last six used URLs.

URLs should be ordered on the configuration page with the most recently used URL at the top of the list. URLs in the list should be selectable and copyable so that users can cut and paste them into the "SAML Metadata URL" box.

The maximum length of the list should be stored as a configuration parameter.

Hook up Travis CI to run tests on pull requests

Once we have the npm test command working (see #33) we can hook up Travis CI so tests are run on pull requests. If we add a ".travis.yaml" file to the root of the project with the following contents, it should work.

language: node_js
sudo: false
script:
  - npm test

We may have to add a ".nvmrc" file to the root of the project with the following contents to tell Travis CI what version of Node to use.

4.4.0

Clarify README around using Awsaml vs. setting up an identity provider for Awsaml

New users have expressed some confusion around running Awsaml. People think they need to set up an identity provider (like Okta) and configure their Amazon account before they can download the binary and run it. We should split the README out into separate documents that cover running Awsaml as a user vs. setting up an identity provider for use with Awsaml. This will also lay the groundwork for being able to provide documentation around identity providers beyond Okta.

Documentation should be Markdown formatted and go into a "docs" folder in the root. The following is probably a good starting point

  • docs/usage.md - Covers how to get binaries and run Awsaml
  • docs/setup.md - Covers how to get set up an identity provider

The README can then be amended with links to the individual documents.

Metadata URL error messages show up after successful authentication

You can get into a state where the "The SAML metadata is invalid." error message is still visible after you've successfully authenticated.

  1. Open Awsaml
  2. Enter an invalid metadata URL like https://github.com/
  3. Click the "Done" button
  4. See the error message?
  5. Enter a valid metadata URL
  6. Click the "Done" button
  7. The error message went away!
  8. Login to your identity provider
  9. Why is the error message back!?

Create an application icon for Awsaml

We need to design an application icon for Awsaml. The general criteria is that the icon must be readable at a 64x64 pixel resolution. The design should be in SVG format so we can scale it to any needed resolution. The icon should be named "awsaml.svg" and go in the "resources" folder at the root of the project.

[Linux] Uncaught exception thrown when starting Awsaml

Originally reported by: @emcanearney-r7

Using the v1.2.0 Linux release of Awsaml.


Starting up Awsaml renders the following:

Uncaught Exception:
SyntaxError: Unexpected end of input
    at Object.parse (native)
    at Storage.load (/home/emcanearney/apps/awsaml-v1.2.0-linux-x64/resources/app.asar/lib/storage.js:26:22)
    at Storage.get (/home/emcanearney/apps/awsaml-v1.2.0-linux-x64/resources/app.asar/lib/storage.js:57:10)
    at EventEmitter.Application.on (/home/emcanearney/apps/awsaml-v1.2.0-linux-x64/resources/app.asar/app.js:35:33)
    at emitOne (events.js:95:20)
    at EventEmitter.emit (events.js:182:7)

screen shot 2016-09-20 at 15 20 11

Better error handling

There's very little error handling in Awsaml. For example, if you put an invalid url into the configuration page, all that shows is a dull red border appears around the SAML Metadata URL field.

In addition, there's no handling around exceptions. They bubble up to electron's handling which pops a stacktrace up in a new window.

We should improve both of these things.

Project: Totally Testable

Awsaml doesn't currently have any automated testing around it. This creates a barrier to entry for contributors, since it's hard to know if your changes broke anything. We should set up automated tests for Awsaml and have them run by Travis CI when pull requests are created.

Issues related to this project are filed under the "totally-testable" milestone.

Electron packaging tools aren't installed with production builds

If you're creating a production build as part of a release process, you run npm install --production to skip all the development dependencies. The gotcha is that the Electron packaging tools get skipped as well. Those need to move out of the devDependencies section of the package.json file and into the dependencies section. Both the electron-packager and electron-prebuilt modules should move.

There's already an --ignore=node_modules/electron flag in the build process, so we don't have to worry about those packages making it into the released builds.

Project: Beautiful Branding

There are a variety of tiny touch points around branding that would be helpful to have when referencing Awsaml. Both a short and long form description as well as a website with screen shots, download links, and documentation on setup, usage, and where to get help, file issues, etc.

Issues related to this project are filed under the "beautiful-branding" milestone.

Project: Prepackaged Providers

Right now, Awsaml only has documentation for Okta as a provider. We should document usage for the other providers that are supported out of the box by Passport-SAML, as well as look into alternative providers like GitHub and Google.

It may also be possible to have Awsaml serve as its own provider. That probably necessitates the refactor from #23. I'm not quite sure what a local Awsaml authentication would look like anyway (YubiKey maybe?).

Issues related to this project are filed under the "prepackaged-providers" milestone.

Convert Awsaml icon to .icns format for Mac

We need to generate .icns icns for Mac builds. Once we have an icon (see #27) we can convert it to an .icns format. The converted icon should be named "awsaml.icns" and go in the "resources" folder at the root of the project.

Project: RESTful Refactor

Awsaml uses the express-react-views library to render its user interface. This means the UI is static and needs the server to push changes to it. This creates a tight coupling between the process of refreshing tokens and the presentation of those tokens.

Instead, the server should expose a RESTful interface for managing tokens. This would allow the UI to be rewritten as a single page application using React directly. It would also simplify the work needed to support managing tokens for multiple AWS accounts simultaneously. The RESTful interface could support an EC2 metadata like API and enable third-party applications to treat the local desktop environment as an EC2 instance.

Work around this project can be completed in stages without impacting other development.

  1. Create a design document describing the RESTful interface (see #24)
  2. Implement the RESTful interface while maintaining the existing server API
  3. Implement the React UI, providing users a toggle to turn it on and off
  4. Deprecate the existing UI and make the React UI the default
  5. Remove the existing UI

Issues related to this project are filed under the "restful-refactor" milestone.

Project: Iconic Identity

Awsaml currently uses the stock Electron icon. To provide better visual distinction between it and other Electron applications, Awsaml should have its own icon. We need several icon file formats to account for all the OSes we support. Plus, the build process needs updated to package the icon.

Issues related to this project are filed under the "iconic-identity" milestone.

Awsaml should display the profile name in the UI

Awsaml writes a named profile to ~/.aws/credentials. The user has to know to look there if they want to configure their CLI tools. Awsaml should display the named profile in the UI and provide and example of command line usage as well.

Hook up Travis CI to lint code on pull requests

Once we have the npm test command working in Travis CI (see #35) we can add lint coverage by extending the "scripts" section of the ".travis.yaml" file with a npm run lint command. The linter should run before the tests are run.

JavaScript error when metadata URL doesn't return XML

You can enter any valid URL in the "SAML Metadata URL" field on the configuration screen. If the data returned isn't valid XML, an uncaught exception is thrown. Try entering "https://www.google.com/" in the configuration screen and then click the "Done" button. See the attached screenshot for the error message that pops up.
uncaughtexception

Add tests around the `AwsCredentials` class

The AwsCredentials class should be the first piece under test since it's pretty self contained. In particular, the following cases should be tested:

  • an error is thrown if $HOME can't be resolved
  • an error is thrown if no credentials are provided
  • an error is thrown if no profile is provided
  • the $HOME/.aws folder is created if it doesn't exist
  • the $HOME/.aws folder has permission bits set to 0700
  • existing profile information in the credentials file is preserved
  • old profile information in the credentials file is overwritten
  • access keys are written to aws_access_key_id keys
  • secret access keys are written to aws_secret_access_key keys
  • session tokens are written to both aws_session_token and aws_secret_token keys

Make potentially sensitive information hidden by default

When I start an awsaml session I get a window that looks like the following:

screen shot 2016-06-30 at 2 18 22 pm

Not that this is a very likely attack vector, but with that window up, someone could capture the information in that window (with a camera? a really good memory?) and then transfer it to another device and use AWS services impersonating me.

Since awsml conveniently writes that data to ~/.aws/credentials already, it also seems unlikely that anyone would really need to copy and paste it from the awsaml GUI to somewhere else.

So, would you consider a modification in which the access key, secret key and session token info is hidden by default in the awsaml GUI, but could be revealed after clicking on a button?

Single click login to existing accounts

@rhodgman-r7 @simonirwin-r7 @bturner-r7 and many others agree that a workflow that requires less button presses would be better.

Today (in the v1.3.1.beta.1 prerelease) to log into an account you've already configured with Awsaml the workflow is:

  1. Open Awsaml (or press logout if already logged in).
  2. Configure the metadata URL in the "configure" field by either:
    • Entering an existing metadata URL by copying and pasting from a "recent login".
    • Entering a brand new metadata URL.
  3. Click "Configure".
  4. Authenticate with your SAML provider when prompted.
  5. Export AWS credentials.

After implementing #49 (recent logins section) the user simply has to press the logout button and repeat these steps to switch accounts.

An improved workflow would be something like:

  1. Open Awsaml (or logout).
  2. Login (configure Awsaml with SAML) via:
    • Clicking a new "login" button for a given account when you have recent logins.
    • Entering a new metadata URL and clicking "Configure'.
  3. Export AWS credentials.

Update Awsaml's build process to inject icons

Awsaml's build process uses electron-packager for packaging. We should be able to add the --icon flag to the build process to create a custom application icon. For now, we can leverage the stock Electron
icons
and update the build process to inject those. Once we have OS specific icons (see #28, #29, and #30), the build process will pick them up. Icons should go in a "resources" folder in the root of the project.

Provide a manual testing guide for Awsaml

The long term goal is to have an automated test suite around Awsaml. For now, we should have a step-by-step guide that describes how to build the binary releases and test them. This may entail additional work to set up some kind of development SAML provider.

White-space characters in the copy-pasta box break some shells

The code-box with generated export ENVAR commands has some trailing white-space characters that break Bash due to slight variations in OS's clipboard semantics AFAIK. On OS X, copy-pasting both lines works as expected. However, on an Ubuntu/Unity desktop, I've observed this breaking the boto/python based aws-cli. Copy-pasting each line individually, being careful not to select past the last printable-character, fixes the issue.

Make profile name configurable

We are currently using awsaml-${session.accountId} as the profile in $HOME/.aws/credentials.

If you are dealing with many AWS accounts or if the accounts you are dealing with have very similar account ids it can become confusing.

This should include changing the call to AwsCredentials.save and updating the refresh view.

Update README to include build status icon

Once Travis CI is wired up to run on pull requests (see #35) we can update the README file to include a build status icon. The following Markdown snippet should go at the top of the README right after the "Awsaml" header.

[![Build Status][build-status-image]][build-status-url]

The build-status-image and build-status-url links should be defined at the bottom of the README.

[build-status-image]: https://travis-ci.org/rapid7/awsaml.svg?branch=master
[build-status-url]: https://travis-ci.org/rapid7/awsaml

Add a "Log Out" button to the refresh page

Users need a way to get back to the configuration page without having to close and restart Awsaml. Adding a "Log Out" button to the refresh page provides that control. When clicked, the "Log Out" button should take the user to the /logout end point. The /logout end point should do the following

  • Allow the user to access it without being authenticated
  • Stop the current refresh interval timer if it's running
  • Clear the current session data
  • Redirect the user to the configuration page

Provide an issue template for Awsaml

When issues are created, there are no clear guidelines around how to tag them, or what details to include. We should add an issue template that documents what should be included in an issue and recommendations on how to tag it. Note that tagging guidelines imply we come up with a simple sensible tagging scheme.

Current thoughts on a tagging scheme are that things are either "enhancement" or "bug". The documentation should include examples of both and thoughts on how to pick between the two. If you need to put both labels on an issue, it should be split it into separate issues.

Project issues e.g. #17, are special. They are unlabeled and provide descriptive information around milestones.

Project: Simply Switchable

The current workflow for using Awsaml v1.1.0 with two AWS accounts is:

  • Open Awsaml
  • Input metadata URL for first account
  • Do work in first account
  • Close Awsaml
  • Open Awsaml
  • Input metadata URL for second account
  • Do work in second account
  • Close Awsaml

This isn't a nice flow and doesn't scale as you add more accounts. Awsaml should have user friendly support for multiple accounts.

To start, we could allow people to name their metadata URLs and have some kind of button on drop down menu for switching. We'd need UI around managing metadata URLs e.g. add new, remove existing, edit existing. Here's a plan for how that can happen; the goal here is to provide incrementally useful functionality.

  1. Add a "Log Out" button to the refresh page (see #48)
  2. Add a "Recent Logins" list to the configuration page (see #49)

Longer term, we could support maintaining tokens for multiple accounts simultaneously. That longer term bit might be easier if we complete the "RESTful Refactor" project first.

Issues related to this project are filed under the "simply-switchable" milestone.

Create a GitHub.io page for Awsaml

We need a landing page for Awsaml that provides a more curated experience than the README of our GitHub project. We can do this with a GitHub.io page. The page should include:

  1. Why Awsaml is useful, what it does, and who should use it (see #43)
  2. What the latest version is and where Awsaml can be downloaded
  3. Links to documentation on configuring Awsaml for administrators

Convert Awsaml icon to .ico format for Windows

We need to generate .ico icons for Windows builds. Once we have an icon (see #27) we can convert it to an .ico format. The converted icon should be named "awsaml.ico" and go in the "resources" folder at the root of the project.

Convert Awsaml icon to .png format for Linux

We need to generate .png icons for Linux builds. Once we have an icon (see #27) we can convert it to a .png format. The converted icon should be named "awsaml.png" and go in the "resources" folder at the root of the project.

Document Awsaml's release process

Once pull requests are accepted to Awsaml, it'd be nice to know when those changes will be released. We should have documentation (in a "docs/releases.md" file) that describes

  • how Awsaml is versioned (semantically)
  • when releases happen (every two weeks on Monday)
  • where the latest release can be found
  • how new releases are built
  • how the descriptive information in a release is formatted and populated

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.