Blog Updates: Minor updates:
- Update labels
Will continue to make minor improvements for this blog!
- wong chee tat :)
Saturday 21 October 2017
Increase Cash Flow
Increase Cash Flow!
Let us increase our Cash Flow!
- Pic from Internet
- wong chee tat :)
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
- wong chee tat :)
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
- wong chee tat :)
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
- wong chee tat :)
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
- wong chee tat :)
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
- wong chee tat :)
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
Homage to the 36 trillion, 119 thousand, 500 Amitabha Buddhas
- wong chee tat :)
Oct 2017 Singapore Savings Bonds - GX17110S
Issuance details - GX17110S
| Bond ID |
GX17110S
|
|---|---|
| Amount available |
$150 million
|
| Issue date |
1 Nov 2017
|
| Maturity date(1) |
1 Nov 2027
|
| Interest payment dates(1) |
The 1st interest payment will be made on 1 May 2018,
and subsequently every six months on 1 Nov and 1
May every year.
|
| Investment amounts |
You can invest a minimum of $500, and in multiples
of $500 up to $50,000 for this issue. The total amount of Savings Bonds held across all issues cannot be more than $100,000. |
| Application period |
Opens: 6.00pm, 2 Oct 2017
Closes: 9.00pm, 26 Oct 2017 Results: After 3.00pm, 27 Oct 2017 Keep track of the important dates with our SSB calendar. |
| Apply through |
DBS/POSB, OCBC and UOB ATMs and Internet Banking,
OCBC Mobile Application from 7.00am - 9.00pm, Mon - Sat, excluding Public Holidays. On 2 Oct 2017, these channels will be open from 6.00pm to 9.00pm. CPF and SRS funds are not eligible. |
This bond will be reflected as "SBNOV17 GX17110S" in your CDP statement and "CDP-SBNOV17" in your bank statement.
Interest rates
* At the end of each year, on a compounded basis
Calculate the interest you will earn based on your desired investment amount using the Interest Calculator.
(1)If this day is not a business day, payment will be made on the next business day.
Should I get?- wong chee tat :)
Scheduled Maintenance - POSB
Scheduled Maintenance - POSB
We are constantly upgrading our systems to bring you a better banking experience. During the periods mentioned below, some of our services will not be available:
iBanking | |||
|---|---|---|---|
Date
|
Maintenance Period
|
Services Under Maintenance
| |
22-Oct-17
|
0120hrs to 0125hrs
|
- MCSA Funds Transfer and Portfolio Enquiry
| |
22-Oct-17
|
0640hrs to 0645hrs
|
- MCSA Funds Transfer and Portfolio Enquiry
| |
22-Oct-17
|
0120hrs to 0645hrs
|
- Online Funds Trading (OFT)
| |
22-Oct-17
|
0120hrs to 1440hrs
|
- Online Equity Trading (OET)
| |
22-Oct-17
|
0300hrs to 0800hrs
|
- No token registration
- No token replacement | |
22-Oct-17
|
0000hrs to 0600hrs
|
- Fast Funds Transfer to Other Bank (New/Existing Payee)
- Adhoc Fast Funds Transfer to Other Bank | |
Digibank App | |||
|---|---|---|---|
Date
|
Maintenance Period
|
Services Under Maintenance
| |
22-Oct-17
|
0120hrs to 0125hrs
|
- MCSA Funds Transfer
| |
22-Oct-17
|
0640hrs to 0645hrs
|
- MCSA Funds Transfer
| |
22-Oct-17
|
0300hrs to 0800hrs
|
- No digital token registration
- No token registration - No token replacement | |
22-Oct-17
|
0000hrs to 0600hrs
|
- Fast Funds Transfer to Other Bank (New/Existing Payee)
- Adhoc Fast Funds Transfer to Other Bank | |
iWealth App | |||
|---|---|---|---|
Date
|
Maintenance Period
|
Services Under Maintenance
| |
22-Oct-17
|
0120hrs to 0125hrs
|
- MCSA Funds Transfer and Portfolio Enquiry
| |
22-Oct-17
|
0640hrs to 0645hrs
|
- MCSA Funds Transfer and Portfolio Enquiry
| |
22-Oct-17
|
0120hrs to 1440hrs
|
- Online Equity Trading (OET)
| |
22-Oct-17
|
03000hrs to 0800hrs
|
- No digital token registration
- No token registration - No token replacement | |
22-Oct-17
|
0000hrs to 0600hrs
|
- Fast Funds Transfer to Other Bank (New/Existing Payee)
- Adhoc Fast Funds Transfer to Other Bank | |
Sweb | |||
|---|---|---|---|
Date
|
Maintenance Period
|
Services under Maintenance
| |
21-Oct-17
|
2200hrs to 2359hrs
|
- Home Loan Application
| |
22-Oct-17
|
0000hrs to 0600hrs
|
- Home Loan Application
| |
DBS PayLah! | |||
|---|---|---|---|
Date
|
Maintenance Period
|
Services under Maintenance
| |
22-Oct-17
|
0000hrs to 0530hrs
0600hrs to 0830hrs |
- Login unavailable
- Intermittent login and disruption of services | |
Public Website | |||
|---|---|---|---|
Date
|
Maintenance Period
|
Services under Maintenance
| |
22-Oct-17
|
0500hrs to 0600hrs
|
- digibank Virtual Assistant will not be available
| |
- wong chee tat :)
JDK 8u151 Update Release Notes
JDK 8u151 Update Release Notes
Java™ SE Development Kit 8, Update 151 (JDK 8u151)
October 17, 2017
The full version string for this update release is 1.8.0_151-b12 (where "b" means "build"). The version number is 8u151.
IANA Data 2017b
JDK 8u151 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.
Security Baselines
The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u151 are specified in the following table:
| JRE Family Version | JRE Security Baseline (Full Version String) |
|---|---|
| 8 | 1.8.0_151-b12 |
| 7 | 1.7.0_161-b13 |
| 6 | 1.6.0_171-b13 |
JRE Expiration Date
The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u151) will expire with the release of the next critical patch update scheduled for January 16, 2018.
For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u151) on February 16, 2018. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.
Notes
core-libs/java.net
Default timeouts have changed for FTP URL handler
Timeouts used by the FTP URL protocol handler have been changed from infinite to 5 minutes. This will result in an IOException from connect and read operations if the FTP server is unresponsive. For example,
new URL("ftp://example.com").openStream().read(), will fail with java.net.SocketTimeoutException in case a connection or reading could not be completed within 5 minutes.
To revert this behaviour to that of previous releases, the following system properties may be used,
sun.net.client.defaultReadTimeout=0, sun.net.client.defaultConnectTimeout=0
JDK-8181612 (not public)
install
Demo references in Solaris install documentation
Demos were removed from package tar.Z bundle(JDK-7066713). There is a separate Demos&Samples bundle beginning with 7u2 b08 and 6u32 b04, but Solaris patches still containSUNWj7dmo/SUNWj6dmo. The 64 bit packages are SUNWj7dmx/SUNWj6dmx
Demo packages remain in the existing Solaris patches; however, just because they are there doesn't mean that they are installed. They will be patched only if the end user has them installed on the system.
The link above is to the Solaris OS Install Directions for the JDK. The SUNWj7dmx package is mentioned in the tar.Z portion of the directions. This is confusing to some as, according to the cited bug, the SUNWj7dmx package shouldn't be part of the tar.Z bundle.
See JDK-8175866
Certificate Changes
Remove revoked Swisscom root certificate "swisscomrootevca2"
One Swisscom root certificate has been revoked by Swisscom and has been removed:
Swisscom Root EV CA 2
alias: "swisscomrootevca2 [jdk]"
DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
JDK-8186330 (not public)
New Features
security-libs/javax.crypto
New Security property to control crypto policy
This release introduces a new feature whereby the JCE jurisdiction policy files used by the JDK can be controlled via a new Security property. In older releases, JCE jurisdiction files had to be downloaded and installed separately to allow unlimited cryptography to be used by the JDK. The download and install steps are no longer necessary. To enable unlimited cryptography, one can use the new
crypto.policy Security property. If the new Security property (crypto.policy) is set in the java.security file, or has been set dynamically by using theSecurity.setProperty() call before the JCE framework has been initialized, that setting will be honored. By default, the property will be undefined. If the property is undefined and the legacy JCE jurisdiction files don't exist in the legacy lib/security directory, then the default cryptographic level will remain at 'limited'. To configure the JDK to use unlimited cryptography, set thecrypto.policy to a value of 'unlimited'. See the notes in the java.security file shipping with this release for more information.
Note: On Solaris, it's recommended that you remove the old SVR4 packages before installing the new JDK updates. If an SVR4 based upgrade (without uninstalling the old packages) is being done on a JDK release earlier than 6u131, 7u121, 8u111, then you should set the newcrypto.policy Security property in the java.security file.
Because the old JCE jurisdiction files are left in <java-home>/lib/security, they may not meet the latest security JAR signing standards, which were refreshed in 6u131, 7u121, 8u111, and later updates. An exception similar to the following might be seen if the old files are used:
Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers! at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)
See JDK-8157561
Changes
security-libs/java.security
Refactor existing providers to refer to the same constants for default values for key length
Two important changes have been made for this issue:
1. A new system property has been introduced that allows users to configure the default key size used by the JDK provider implementations of KeyPairGenerator and AlgorithmParameterGenerator. This property is named "jdk.security.defaultKeySize" and the value of this property is a list of comma-separated entries. Each entry consists of a case-insensitive algorithm name and the corresponding default key size (in decimal) separated by ":". In addition, white space is ignored.
By default, this property will not have a value, and JDK providers will use their own default values. Entries containing an unrecognized algorithm name will be ignored. If the specified default key size is not a parseable decimal integer, that entry will be ignored as well.
2. The DSA KeyPairGenerator implementation of the SUN provider no longer implementsjava.security.interfaces.DSAKeyPairGenerator. Applications which cast the SUN provider's DSA KeyPairGenerator object to ajava.security.interfaces.DSAKeyPairGenerator can set the system property "jdk.security.legacyDSAKeyPairGenerator". If the value of this property is "true", the SUN provider will return a DSA KeyPairGenerator object which implements thejava.security.interfaces.DSAKeyPairGenerator interface. This legacy implementation will use the same default value as specified by the javadoc in the interface.
By default, this property will not have a value, and the SUN provider will return a DSA KeyPairGenerator object which does not implement the forementioned interface and thus can determine its own provider-specific default value as stated in thejava.security.KeyPairGenerator class or by the "jdk.security.defaultKeySize" system property if set.
JDK-8181048 (not public)
core-libs/java.util:collections
Collections use serialization filter to limit array sizes
Deserialization of certain collection instances will cause arrays to be allocated. TheObjectInputFilter.checkInput() method is now called prior to allocation of these arrays. Deserializing instances of ArrayDeque, ArrayList, IdentityHashMap, PriorityQueue,java.util.concurrent.CopyOnWriteArrayList, and the immutable collections (as returned by List.of, Set.of, and Map.of) will call checkInput() with a FilterInfo instance whosestyle="font-family: Courier New;">serialClass() method returns Object[].class. Deserializing instances of HashMap, HashSet, Hashtable, and Properties will call checkInput()with a FilterInfo instance whose serialClass() method returns Map.Entry[].class. In both cases, the FilterInfo.arrayLength() method will return the actual length of the array to be allocated. The exact circumstances under which the serialization filter is called, and with what information, is subject to change in future releases.
JDK-8174109 (not public)
security-libs/java.security
keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms
With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing
TrustedCertificateEntry, either in the keystore directly operated on or in the cacertskeystore when the -trustcacerts option is specified for the -importcert command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the filecert contains a CA certificate signed with a weak signature algorithm, keytool -printcert -file cert and keytool -importcert -file cert -alias ca -keystore ks will print out a warning, but after the last command imports it into the keystore, keytool -list -alias ca -keystore ks will not show a warning anymore.
Precisely, an algorithm or a key is weak if it matches the value of the
jdk.certpath.disabledAlgorithms security property defined in theconf/security/java.security file.
See JDK-8171319
security-libs/java.security
New defaults for DSA keys in jarsigner and keytool
For DSA keys, the default signature algorithm for
keytool and jarsigner has changed from SHA1withDSA to SHA256withDSA and the default key size for keytool has changed from 1024 bits to 2048 bits.
Users wishing to revert to the previous behavior can use the
-sigalg option of keytool andjarsigner and specify SHA1withDSA and the -keysize option of keytool and specify 1024.
There are a few potential compatibility risks associated with this change:
- If you have a script that uses the default key size of
keytoolto generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex:keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ...
keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ...it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA:keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bitsThe workaround is to remove the-sigalgoption and use the stronger SHA256withDSA default or, at your own risk, use the-keysizeoption ofkeytoolto specify a smaller key size (1024). - If you use
jarsignerto sign JARs with the new defaults, previous versions (than this release) of JDK 6 and 7 do not support the stronger defaults and will not be able to verify the JAR.jarsigner -verifyon an earlier release of JDK 6 or 7 will output the following error:jar is unsigned. (signatures missing or not parsable)If you add-J-Djava.security.debug=jarto thejarsignercommand line, the cause will be output:jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not availableIf compatibility with earlier releases is important, you can, at your own risk, use the-sigalgoption ofjarsignerand specify the weaker SHA1withDSA algorithm. - If you use a
PKCS11keystore, the SunPKCS11 provider does not support theSHA256withDSAalgorithm.jarsignerand somekeytoolcommands may fail with the following exception ifPKCS11is specified with the-storetypeoption, ex:keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKeyA similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the-sigalgoption ofkeytooland specify SHA1withDSA.
See JDK-8057810
security-libs/java.security
Add warnings to keytool when using JKS and JCEKS
When keytool is operating on a JKS or JCEKS keystore, a warning may be shown that the keystore uses a proprietary format and migrating to PKCS12 is recommended. The keytool's -importkeystore command is also updated so that it can convert a keystore from one type to another if the source and destination point to the same file.
JDK-8182879 (not public)
security-libs/java.security
keytool now prints out information of a certificate's public key
Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm:
<size>-bit RSA key", where <size> is the key size in bits (ex: 2048).
See JDK-8029659
Bug Fixes
This release contains fixes for security vulnerabilities described in the Oracle Critical Patch Update. For a more complete list of the bug fixes included in this release, see the JDK 8u151 Bug Fixes page.
Installed
- wong chee tat :)
Subscribe to:
Posts (Atom)